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ABSTRACT 


Line-of-sight (LOS) calculation for the Janus combat simulation model is critical to 
the processes being simulated and impacts the run speed (ratio of game time to real time), 
since it may be the single most computationally expensive algorithm in simulation. 

This thesis presents design and implementation of a transputer network with the 
purpose of providing an efficient LOS calculation in a distributed memory and computing 
environment. The approach taken was to use a processor farming method to speed up the 
LOS calculation. The programs were implemented on a network of 15 transputers using 3L 
Parallel C++ (version 2.1.1) programming language. A 1-meter resolution terrain database 
of Fort Hunter Liggett, California was used to get more reliable LOS results. 

Expected gain of our system was 3.873 (VTs). After timing tests, we found that we 
could speed up the LOS calculation by a factor of 2.581 when comparing the 15 transputer 
configuration to a conventional processor which is equivalent to a single transputer. The 
difference between expected gain and actual gain was found to be the communication 
overhead in the network of transputers. We stated that further significant improvements can 
be provided by using our approach with more memory and faster transputers. 
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I. INTRODUCTION 


A. BACKGROUND 
1. Janus 

The Janus simulation was fielded in 1978 [Ref. 1]. It was developed as a nuclear 
effects modeling tool by Lawrence Livermore National Laboratories and became known as 
Janus(L). TRADOC Analysis Command (TRAC) at White Sands Missile Range (WSMR) 
modified Janus(L) to meet Army combat development needs. The modified Janus(L) 
model became known as JanusfT). The Army realized the value of the system for use in the 
training arena, and tasked TRAC-WSMR with developing a multipurpose system from the 
best of Janus(L) and Janus(T), which was tamed Janus(A). Through enhancements and 
upgrades, Janus(A) has reached a version level of 4.0 as of January 1994. 

The Janus model simulates battle between Blue and Red units. It supports conflict 
from individual systems and company-sized units through brigade/regimental-sized units. 
It is an interactive, two-sided, closed, stochastic, ground combat simulation featuring 
precise color graphics. Janus is “interactive” in that the command and control functions are 
entered on workstations by military analysts who decide what to do in crucial situations 
during simulated combat. ‘Two-sided” refers to the two opposing forces, blue and red, 
directed simultaneously by two sets of players. “Closed” means that the disposition of 
opposing forces is largely unknown to the players in control of the other force. “Stochastic” 
refers to the way the system determines the results of actions such as direct fire 
engagements; according to the laws of probability and chance. “Ground combat” means 
that the principal focus is on ground maneuver and artillery units, although Janus also 
models weather and its effects, day and night visibility, engineer support, minefield 
employment and breaching, rotary and fixed wing aircraft, resupply and a chemical 
environment. Janus is an event-driven simulation. 



2. The Transputer 


The term “transputer” is an acronym for "transistor computer” where it reflects 
the ability of this device to be used as a system’s building block, much like the transistor 
was in the past [Ref. 2]. The nice feature of the transputer is that it adds a new level of 
abstraction, which provides a very simple way to design a concurrent system. As a formal 
definition we could state that the transputer is a single-chip microcomputer that has its own 
local memory and four communication links. The links may be thought as of as small 
special purpose processors which steal no cycles from the main CPU, in such a way that we 
could have all four links and the CPU working at the same time, without degrading the 
performance of the program’s execution. 

The transputer is a parallel microprocessor, generally categorized as a Multiple 
Instruction Multiple Data (MIMD) computer [Ref. 3] [Ref. 4:pp. 498-500]. This means that 
transputers are used to execute different operations on separate data at the same time. This 
is somewhat like a football team where individual players execute their own special 
assignments together during a play. A transputer operates as a stand-alone machine or as a 
processing element interconnected by their links to form computing arrays and networks. 
Modular design enables transputers to be used together in arbitrary numbers to support a 
broad range of applications, and the inherit redundancy of multiprocessing can be utilized 
for fault tolerance. 

B. SCOPE OF THESIS 

Line-of-sight (LOS) is a central process in combat simulations that works at item 
level. The LOS algorithm is critical to the processes being simulated and impacts the run 
speed (ratio of game time to real time), since it may be the single most computationally 
expensive algorithm in the simulation. 

This study is focused specifically on the following two objectives: 
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1. To implement an efficient calculation of LOS in a distributed memory environment 
by using transputers and 1-meter resolution terrain database. 

2. To show that the usage of 1-meter resolution terrain database for LOS calculation 
purposes gives more precise and reliable results than the current 50 or 100-meter resolution 
terrain databases. 

C. THESIS ORGANIZATION 

This thesis is presented in six chapters and three appendices. 

Chapter I is the introduction to the problem and the background for Janus combat 
simulation system and the transputer. 

Chapter II describes the current issues about parallel computing with transputers. 

Chapter IE presents a detailed problem statement for this thesis. The current issues 
about Janus which are PEGASUS terrain database organization and the algorithm for LOS 
calculation are described in this chapter. 

Chapter IV describes the transputer implementation of LOS calculation in both 
hardware and software aspects. 

Chapter V presents the experimental results of the transputer implementation of LOS 
calculation. 

Chapter VI states the conclusions and reconunendations for further research. 

Appendix A includes the Sun SPARC Station source code. 

Appendix B includes the Host Computer (PC) source code. 

Appendix C includes the source code for reading terrain data from Pegasus Database. 
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IL TRANSPUTERS AND PARALLEL COMPUTING 


A. PARALLELISM 

In the first computing wave, scientific and business computers were more or less 
identical as they were all big and slow [Ref. 6:p. 1]. Even the early electronic computers 
were not very fast. This was the “prehistory of computing”, where computing had to be 
employed at any cost. 

The second and third waves brought on mainframes, minis, and finally micros. This 
diversity of computing caused a number of niches to develop which broadened and 
deepened the computer industry. Scientific and business computing went their separate 
ways, and there seemed to be a computer in just about everyone’s price range. 

But the original power users who pioneered computing continued to emphasize speed 
above all else. Single-processor supercomputers achieved unheard of speeds beyond 100 
million instructions per second, and pushed hardware technology to the physical limits of 
chip building. But soon this trend will come an end, because there are physical and 
architectural bounds which limit the computational power that can be achieved with a 
single-processor system. 

We are now enjoying the Parallel Wave [Ref. 6:pp. 1-5] of computing, where 
performance is enhanced by using multiple processors. Parallelism is the process of 
performing tasks concurrently. It has been touted as a solution to the problem of making 
computers faster and faster. When the physical limits for single-processor systems are 
reached, parallelism will be the only course. However, even before the speed limit is 
reached, there is an economic motivation to use parallel processing in place of faster and 
more expensive single-processor systems. Indeed, the economic advantage of low-cost, 
multiple processing systems was realized in the mid-1980s. Hence, the 1990s were poised 
for the decade of parallelism simply due to economic forces. 



Many parallel architectures have been discussed in the past, and there are several 
superminicomputer parallel systems available today. However, most of these are unable to 
provide the very wide range of price/performance that parallel processing promises and that 
transputer-based systems can provide [Ref. 5]. 

To understand this, it is worth examining the normal approach to parallel systems 
design. Most parallel systems are constructed by connecting up multiple computers with a 
single high speed bus. A simplified system can be imagined, consisting of multiple 
processors sharing a single global memory accessed via a single high performance bus. 

This shape of system will provide very disappointing results for obvious reasons; a 
processor can only access memory when no other processor is accessing memory. With 
high performance processors, this will provide an upper limit of perhaps two or three 
processors before performance stops increasing. It is possible to speed the system up, but 
only by use of memory that is very much faster than the processors. This is expensive. 

In more realistic system each processor has some private, local memory in addition 
to bus access to global memory. The local memory could be organized as either a private 
address space, or a sufficiently large cache. Now, it is possible to imagine a system where 
a processor spends perhaps 90% of its time accessing local memory and only 10% 
accessing the shared store. Then with reasonably-priced memory it should be possible to 
build a computer which can use perhaps twenty or thirty processors before saturating. 

The bottleneck in this system is the shared resource, either the bus or the memory. 
The bus itself is a poor choice for interconnect in any case; not only does its logical 
performance degrade as more processors contend for it, the extra electrical loads imposed 
by adding processors to the bus either slow the system down as more machines are added, 
or set a much lower bandwidth on the bus for lower processor counts. 

Whichever is the bottleneck at present, the apparently inexorable improvement in 
semiconductor technology will arrange for it to be the bus since affordable memory and 
processor speeds are increasing faster than improved backplane technologies. As a result, 
this sort of system is guaranteed non-future proof; as device speeds increase, the system 



performance flattens out since the maximum number of processors usable before bus 
saturation reduces with time. 

The system architecture can be changed slightly to remove the straitjacket imposed 
by the bus. An obvious improvement is to use multiple buses, probably arranged in some 
regular, structured manner, like a hierarchy. Now, clusters of computers, each with its own 
local memory, share some cluster memory via a cluster bus. Clusters are connected by other 
buses; these buses themselves can have memory. Then, assuming that 90% of accesses are 
local, and that 90% of the non-local accesses are to the local cluster shared memory, the 
earlier arguments suggest that for a well-behaved problem, a twenty cluster system could 
be built, with each cluster having twenty processors. 

This solution should work for a range of applications, but the amount of logic and 
interconnect needed to implement it makes it expensive. It has another problem, too; while 
it is an acceptable architecture for a single, centralized computer, shared buses do not seem 
to be an appropriate paradigm for distributed parallel systems. 

These criticisms can be resolved by a small change in attitude to the system 
architecture, and then a re-implementation. Assume that the system is an actual parallel 
computing system, rather than just a collection of computers each with access to some 
shared system resource; then the processors must be interacting with one another. Each will 
be working on a portion of the problem, and will interchange partial results with other 
processors as they jointly progress toward completing the program. To do this, each 
machine will likely provide the equivalent of mailboxes, where the other processors can 
leave their own results and their requests for information. 

But if the processors are cooperating by exchanging messages, then there is no need 
to use shared memory to implement the communication. Instead, direct interprocessor data 
transfer channels can be used to Direct Memory Access (DMA) [Ref. 4:pp. 297-301] 
information from one processor to another. Given such a mechanism, we cure several 
problems at once: as we add processors, we add interprocessor bandwidth; the processors 
do not need to be physically located together, and so can be components of a distributed 
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system without necessarily altering the system design or software; and the cost of the 
interprocessor hardware can be much reduced from bus costs (since, for example, there is 
no need for an address, we can save by not having address lines; since there is exactly one 
destination for each driver, the electrical design is simpler). 

This is the system architecture chosen for the transputer. Each transputer comes with 
one or more interprocessor links, each one DMA-driven to ensure that communication can 
take place in parallel with computation. Transputers further reduce system cost by using 
serial interconnect; minimizing pin count reduces transputer cost and interconnect cost, 
eases board layout and minimizes power consumption. 

B. THE DMMOS TRANSPUTER 

The transputer [Ref. 7:pp. 7-30] was developed by INMOS Limited of Bristol, United 
Kingdom, and has since expanded into a family of very large scale integrated (VLSI) 
components with different capabilities. Since the transputer is a component designed to 
exploit the potential of VLSI, that technology allows large numbers of identical devices to 
be manufactured cheaply. For this reason, it is attractive to implement a concurrent system 
using a number of identical components, each of which is customized by an appropriate 
program. The revolutionary architecture of the transputer enables the potential of 
concurrency to be realized for the first time, making today’s applications easier to 
implement and creating a new dimension for tomorrow’s systems. 

The transputer uses silicon capability to make programming simpler and to make 
engineering easier than for any previous microprocessor. The architecture has been 
optimized to obtain the maximum of functionality for the minimum of silicon. It allows 
different trade offs between performance and cost, always giving an intrinsic advantage 
over older architectures. The architecture is future-proof. It spans the range of 
applications from microcontrollers to supercomputers. Transputers will exploit future 
levels of integration by increasing the amount of processing, memory, communications and 
concurrency within the same architecture. 



A typical member of the transputer family is a single chip containing processor, 
memory, and communication links which provide point to point connection between 
transputers. The transputer provides a direct implementation of the process model of 
computing. A process is an independent computation, with its own program and data, 
which can conununicate with other processes executing at the same time. Communication 
is by message passing, using explicitly defined channels. 

The transputer is designed so that it can implement a set of concurrent processes. 
Special instructions share the processor time between the concurrent processes and perform 
interprocess communication. 

In addition, the transputer is designed so that its external behavior corresponds to the 
formal model of a process. As a consequence, it is possible to program systems containing 
multiple interconnected transputers in which each transputer implements a set of processes. 
Since a program is defined as a set of processes, it can be mapped onto such a system in a 
variety of ways, such as minimizing cost, or optimizing throughput, or maximizing the 
responsiveness to specific events. 

The transputer specifically implements the concept of communicating sequential 
processes (CSP) defined by C.A.R. Hoare [Ref. 8] and to be used as a building block for 
distributed computing systems. The CSP concept describes the interactions between 
programs that execute in parallel. 

1. Communicating Sequential Processes 

Hoare’s Communicating Sequential Processes (CSP) is one model for concurrent 
or parallel programming, and it is central to the design of the transputer. In CSP, a program 
is a collection of processes which can be combined to execute sequentially on a single 
processor or in parallel on multiple processors.The data space for any process executing in 
parallel is disjoint, thus alleviating the need for sharing memory between processors. 
Although shared memory is not available, processes must still communicate with each 



other. Therefore, CSP utilizes message passing between any pair of parallel processes via 
declared communication channels between two processes. 

In order for the concurrent processes to communicate, message passing must be 
synchronized. Such communication occurs when one process names another as destination 
for output and the second process names the first as source for input. This allows the value 
to be output by the source process to be copied into the destination process. Note that the 
synchronization imposes a requirement that an output (input) command must be delayed 
until the corresponding input (output) command in the other process is ready to be 
executed. 

2. Transputer Architecture 

Several versions of the transputer are currently available. This thesis considers 
transputer types IMS T800 and IMS T805^ The following sections describe the features of 
an IMS T800 20MHz transputer. A complete description of all currently available 
transputers can be found in [Ref. 7] and [Ref. 9], A block diagram of an IMS T8(X) 
transputer is shown in Figure 2.1. 

a. Overall 

The IMS T800 is a 64 bit floating point nnember of a family of transputers, all 
which are consistent with the INMOS transputer architecture. It integrates a 32 bit 
microprocessor, a 64 bit floating point unit, four standard transputer communication links, 
4Kbytes on-chip RAM for high speed processing, a configurable memory interface and 
peripheral interfacing on a single chip, using a 1.5 micron CMOS process. 


1. T805 is a new version crfTSOO. They are essentially same processors and our lab has a mixture of 
T800 and T805 transputers. 




Figure 2.1: IMS TSOO Block Diagram of the 32-bit IVansputer 





b. Central Processor 

The 32 bit processor provides 10 MIPs performance. The design achieves 
compact programs, efficient high level language implementation and provides direct 
support for the Occam (a programming language that will be mentioned later) model of 
concurrency. Procedure calls, process switching and interrupt latency are all sub¬ 
microsecond. The processor shares its time between any number of concurrent processes. 
A process waiting for communication or a timer does not consume any processor time. Two 
levels of process priority enable fast interrupt response to be achieved. 

c. Floating Point Unit 

The 64 bit floating point unit provides single length and double length 
operation according to the ANSI-IEEE 754-1985 standard for floating point arithmetic and 
able to perform floating point arithmetic operations concurrently with the processor; 
sustaining in excess of 1.5 Mega Flops. 

The floating point unit (FPU) on the T800 consists of a microcoded 
computing engine which operates concurrently with and under the control of the Central 
Processing Unit (CPU). It contains a three deep floating point evaluation stack on which 
floating point numbers, represented in the IEEE format can be manipulated. All data 
communication between memory and the floating point unit is done under the control of 
the CPU. 

d. Memory System 

The 4Kbytes of on chip static RAM provide a maximum data rate of 80 
Mbytes/sec with access for both the processor and links. The IMS T800 can directly access 
a linear space up to 4 Gbytes. The 32 bit wide external memory interface uses multiplexed 
data and address lines provides a data rate up to 26.6 Mbytes/sec. A configurable memory 
controller provides all timing, control and DRAM refresh signals for a wide variety of 
memory systems. Internal and external memory appear as a single continuous address 
space. 
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e. Links 


The IMS T800 uses a DMA block transfer mechanism to transfer messages 
between memory and another transputer product via the INMOS links. The link interfaces 
and the processor all operate concurrently, allowing processing to continue while data is 
being transferred on all of the links. 

The four standard INMOS serial links on the IMS T800 give a unidirectional 
transmitted data rate of 1.7 Mbytes/sec and a combined (bidirectional) data rate per link of 
2.3 Mbytes/sec, at a link speed of 20 Mbits/sec. Link speeds of 10 Mbits/sec and a 5 Mbits/ 
sec are also available on the IMS T800 making the device compatible with all other INMOS 
transputer products. 

/. Peripheral Interface 

The memory controller supports memory mapped peripherals, which may use 
DMA. Links may be interfaced to periplKrals via an INMOS link adaptor. A peripharal can 
request attention via the event pin. 

g. Error Handling 

High-level language execution is made secure with array bounds checking, 
arithmetic overflow detection etc. A flag is set when an error is detected. The error can be 
handled internally by software or externally by sensing the error pin. 

h. Programming IMS T800 

The IMS T800 transputer can be programmed in several languages including 
Occam, C, C++, Ada, Fortran and Pascal. 

L Processes And Concurrency 

The transputer provides direct support for concurrency. It has a microcoded 
scheduler which enables any number of concurrent processes to be executed together, 
sharing the processing time. This removes the need for a software kernel. 
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A process starts, performs a number of actions, and then either stops without 
completing or terminates complete. Typically, a process is a sequence of instructions. A 
transputer can run several processes concurrently^. Processes may be assigned either high 
or tow priority, and there may be any number of each. 

At any time, a concurrent process may be 

Active - Being executed 

- On a list waiting to be executed. 

Inactive - Ready to input 

- Ready to output 

- Waiting until a specified time. 

The scheduler operates in such a way that inactive processes do not consume 
any processor time. It allocates a portion of the processor’s time to each process in turn. 
Each process runs until it has completed its action, but is descheduled while waiting for 
communication from another process or transputer, or for a time delay to complete. 

j. Priority 

The IMS T800 supports two levels of priority. Priority 1 (low priority) 
processes are executed whenever there are no active priority 0 (high priority) processes. 

High priority processes are expected to execute for a short time. If one or more 
high priority processes are able to proceed, then one is selected and runs until it has to wait 
for a communication, a timer input, or until it completes processing. If no process at high 
priority is able to proceed, but one or more processes at low priority are able to proceed 
then one is selected. Low priority processes are periodically timesliced to provide an even 
distribution of processor time between computationally intensive tasks. 

Note that the intention of having two priority levels for processes is to allow 
those high priority tasks, which must be executed when they are invoked, to preempt a 
currently executing low priority process and execute to completion. It is important that the 


2. This is actually a time-sharing for a single CPU system. 



high priority tasks have a very short execution time (less than one slicetime period). 
Otherwise the low priority processes, which should be the computation intensive processes, 
will not be given fair access to the processor. 

k. Communications 

Communications between processes is achieved by means of channels. 
Process communication is point-to-point, synchronized and unbuffered. As a result, a 
channel needs no process queue, no message queue and no message buffer. 

A channel between two processes executing on the same transputer is 
implemented by a single word in memory; a channel between processes executing on 
different transputers is implemented by point-to-point links. The processor provides a 
number of operations to support message passing, the most important being input message 
and output message. 

The input message and output message instructions use the address of the 
channel to determine whether the channel is internal or external. Thus the same instruction 
sequence can be used for both, allowing a process to be written and compiled without the 
knowledge of where its channels are connected. 

The process which first becomes ready must wait until the second one is also 
ready. A process performs an input or output by loading the evaluation stack with a pointer 
to a message, the address of a channel, and a count of the number of bytes to be transferred, 
and then executing an input message or output message instruction. Data is transferred if 
the other process is ready. If the channel is not ready or is an external one the process will 
deschedule. 

3. Programming Languages 

There are several languages which can be used to write programs for use on the 
transputer. Among these are Occam, Alsys-Ada, 3L’s Parallel C, C++, Pascal and Fortran. 
Three of the languages were considered for this thesis. These three languages were Occam 
[Ref. 10], Alsys-Ada [Ref. 11], and 3L’s Parallel C++ [Ref. 12] [Ref. 13]. 
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a. Occam Programming Language 

Occam [Ref. 10] is a high level programming language that is designed to run 
concurrent processes on a network of processing components (e.g. transputers). There are 
two prime concepts in Occam; they are concurrency and communication. These allow 
processes to run simultaneously and transfer information, via channels, from process to 
process. It is based on concepts founded by David May in Experimental Programming 
Language and Tony Hoare in Communicating Sequential Processes. 

It allows processes running on a transputer system to communicate only 
through channels. These channels are asynchronous, but require the send and receive 
processes to be ready to send and receive at the same time. This idea of being ready to send 
and receive simultaneously is known as rendezvous. 

Occam has five kinds of constructions that arc used to build a process from 
smaller processes (primitive or other). These constructions are; 

- IF: This construction guards a number of processes by a boolean expression. 

- CASE: This construction is used to select one of a number of options. 

- WHILE: This construction is used for loops. 

- PAR: This construction has the effect of allowing the processes within its 
bounds to execute in parallel. 

- ALT: This construction is used to allow a processor to select only one of 
several guarded processes for execution. The process whose guard is first found to be true 
is selected. 

This language allows the programmer to concentrate on a small, manageable 
set of processes which can then be connected with other sets of processes. In Occam a set 
of processes or a set of interconnected processes can be regarded as a single process. 

The above features make Occam a powerful and versatile language. It has not 
gained wide acceptance thus far probably due to the limited use of multiprocessor 
(transputer) systems and due to the development of parallel versions of other widely used 
languages. 



b. A Isys A da Programming Language 


In October 1989, Alsys produced the first compiler capable of supporting 
multi-processor programming in Ada [Ref. 11]. Alsys Ada Compilation System consists of 
the compiler and binder, operating in the Alsys Multi-Library Environment. The compiler 
generates executable code for transputer for T4 or T8 transputer targets. Multi-Library 
Environment provides a powerful way of managing Ada development efforts. It allows 
compilation units to be flexibly shared among libraries, and eliminates the need to copy 
library units to share them, along with the associated version control problems. 

Although it has the features mentioned above, we decided against using it, 
because the compilation time is too long when compared to the other languages. 

c. JL’s Parallel C++ Programming Language 

(1) Abstract Model. The treatment of parallel processing in transputer 
systems is based on the idea of communicating sequential processes which is explained in 
part B of this chapter. In this model, a computing system is a collection of concurrently 
active sequential processes which can only communicate with each other over channels. A 
channel connects exactly one process to exactly one other process and can only carry 
messages in one direction. Each process can have any number of input and output channels, 
but note that the channels in a system are fixed; new channels cannot be created during its 
operation. A process could be a bit of hardware or a software module; in particular it may 
also be another complex system, itself consisting of a number of communicating processes. 

(2) Hardware Model The transputer was designed to be used as a 
component in concurrent systems. Each transputer processor has foiu- Inmos links, to 
connect it with other transputers. Each link has two channels, one in each direction. These 
hardware channels provide synchronized, unidirectional communication. 

Arbitrary networks of transputers can be constructed simply by 
connecting their links together with ordinary wires, the only limitation being that each 
processor cannot be directly connected to more than four others. A transputer can therefore 
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be viewed as a single process in a multi-transputer system. However, it is also possible for 
any number of concurrent processes to be run on an individual transputer. Any word in the 
transputer’s memory may be used as a channel to connect one internal process to another. 
The address of such a channel word is used to identify it to the transputer instructions (and 
Parallel C++ functions) which send or receive messages. The contents of the word are used 
by the hardware to synchronize sending and receiving processes. 

From a program’s point of view, these internal channels and the hardware 
link channels are identical. The same instructions (or parallel C++ functions) are used to 
send and receive messages on both internal channels and the hardware link channels. 
Hardware link channels arc identified by special fixed addresses, but internal channels have 
addresses aUocated by software. 

The equivalence of internal channels to hardware link channels means it 
is possible to develop a parallel system on a single transputer and then move some of its 
processes onto other transputers without having to recompile any code. 

(3) Software Model. Parallel C++ is based on the same abstract model of 
communicating sequential processes as the transputer hardware. 

A complete application is viewed as a collection of one or more 
concurrently executing tasks. Each task has its own region of memory for code and data, a 
vector of input ports, and a vector of output ports. The port vectors arc passed to the task 
as arguments to its main function. The code of a task is a single transputer image (.M) file 
generated by the ordinary linker, linkt. 

Tasks can be treated as atomic building blocks for parallel systems, to be 
wired together rather like electronic components. Indeed, several such basic building-block 
tasks are supplied with the compiler. 

Each element in the input and output port vectors is of type “pointer to 
channel word”, (*CHAN). Ports are bound to real channel addresses by configuration 
software external to the task itself; the bindings can be changed without recompiling or 
relinking the task. Extended C++ run-time library functions supplied with the compiler 
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allow C++ programs to send and tecerve messages over the channels bound to a task’s 
ports. 

The configuration software also provides ways of specifying which 
software tasks are to be run on which hardware processors. Each processor can support any 
number of tasks, limited only by available memory. 

Tasks placed on the same processor can have any number of 
interconnecting channels. Tasks placed on different processors can only be connected 
where physical wires connect the processors’ links. Each logical connection between two 
tasks placed on different processors is assigned exclusive use of one the physical link 
channels connecting the processors. The number of interconnections between tasks on 
different processors is therefore limited by the number of hardware links each one has. 

(4) Parallel Execution Threads. The software features described so far 
allow us to build parallel systems by connecting together the ports of a number of relatively 
independent tasks. In particular, all the tasks have separate code and data, and are only 
allowed to communicate with each other by sending messages over channels. 

All of the code of a task can be written in an ordinary sequential language, 
except for one extra feature needed by languages based on the communicating sequential 
processes idea. This extra feature is a way of making a process wait until a message is 
received on any one of a number of input channels. In Parallel C++, it is catered for by the 
ability to create new concurrent threads of execution within a task. The task creates one 
thread for each input channel. Each thread executes a sequential message input call and 
handles messages received on that channel. Each one of Parallel C’s threads has its own 
stack (allocated by its creator), but shares its code, and all of its static and heap data, with 
any other threads in the same task. Semaphore functions in the run-time library are used to 
prevent threads to interfering with each other. 

(5) Configuring An Application. Once an application has been designed 
and written as a collection of communicating tasks, it is loaded into physical network of 
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transputers. First, each individual task is built by compiling all its source files with the C++ 
compiler and using the linker (linkt) to combine the resulting binary (.bin) files with the 
Parallel C++ run-time library to produce a task image (.W) file. Then, a bootable 
application image file must be generated fi’om the component task (.b4) files. The program 
which does this is called the configurer. It is driven by a user-supplied configuration file 
which specifies: 

* the hardware configuration (processors, and the wires connecting them) 
on which the application is to be run; 

* the names of the .b4 files containing the component tasks of the 

application; 

* the connections between the various tasks’ ports; 

* the placement of particular tasks onto particular tasks onto particular 
processors in the physical network. 

The output of the configurer is an application file which can booted into 
the specified hardware network and run using the same (^server program used for simple 
stand-alone programs. The afserver task is an ordinary MS-DOS executable (.exe) file that 
runs on the PC. It loads executable .b4 files into the transputer and also acts as a file server, 
handling I/O requests made by the transputer. The afserver and the transputer execute in 
parallel and communicate via an INMOS link. The messages sent to the afserver are 
normally generated by the Parallel C++ run-time library. It converts I/O operations into 
messages requesting the afserver to perform MS-DOS operations and then waits for the 
afserver to reply. 

(6) Processor Farms. The tools described so far allow you to build 
applications which execute on any transputer network the wiring of which can be specified 
in advance in a configuration file. For many parallel computations it is useful to be able to 
create applications which will automatically configure themselves to run on any network 
of transputers. Such applications will automatically run faster when more transputers are 
added to a network, without recompilation or reconfiguration. 
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Parallel C-h- allows us to create applications like this, provided the 
application can be implemented by a processor farm, and provided that there is enough 
memory on each processor in the network to support the required loading and message 
handling software. 

The processor farm is a method of building applications for the transputer. 
Many users have found it a useful technique, for the following reasons: 

* It takes full advantage of the transputer’s parallel processing facilities 
and the ability of transputers to work together in groups. 

* Many existing sequential programs can be converted into processor 
farms without much difficulty. 

* A processor farm is not restricted to a particular network of transputers, 
but will automatically take advantage of the processors it finds. 

A processor farm includes two independent programs, or tasks, written by 
the user. These are called the master task and the worker task. There is only one copy of the 
master task, and this is placed on the root transputer, that is, the transputer which is directly 
connected to the host. A copy of the worker task is placed on every transputer in the 
network. 

The function of the master task is to break up the job which is to be done 
into a number of small, independent sub-jobs, each of which is performed by one of the 
copies of the worker task. The master does this by sending details of the sub-job to be done 
to the worker task. The worker task sends the results of its work back to the master task, 
which combines it with the results from all the other worker tasks. The worker task is 
written in such a way that immediately after sending its results back to the master, it is ready 
to receive details of another sub-job, and so on. 

The communication between the master and the workers can be in two 
ways. Either another task called router can be written by the user, or special procedures 
which are included in the run-time libraries of the parallel languages and automatically 
added to the processor farm can be used. 





m. DETAILED PROBLEM STATEMENT 


A. PEGASUS DATABASE 

1. Introduction 

The PEGASUS Perspective View Database (PVDB) [Ref. 14] is a geographic 
database containing elevation data, gray shades taken from aerial photographs, vegetation 
heights, and other information required for perspective view generation. The PVDB comes 
in four resolutions: 1-, 4-, 16-and 64-meter. 

The Fort Hunter-Liggett (FHL) PVDB covers a rectangular area on the ground 
measuring 32x28 kilometers. Its southwest comer is at UTM coordinates 43328,63904 and 
its northeast comer is at UTM 76095,92575. The latitude and longitude of these two points 
are approximately 35° 48'N, 121° 25'W and 36° 4' N, 121° 4'W. 

2. Database Organization 

The PVDB is organized as a collection of tiles, blocks, and posts (see Figure 3.1, 
Figure 3.2 and Figure 3.3). A post is the smallest element in the database and covers an area 
on the ground measuring 1x1,4x4,16x16, or 64x64 meters for the 1-, 4-, 16-, and 64-meter 
databases respectively. A post is the only database element for which the area of coverage 
is resolution dependent. 

A block is a collection of posts that always covers an area on the ground 
measuring 256x256 meters, but the number of posts in a block depends on the resolution. 
A block in the 1-meter PVDB contains 256x256 posts, a 4-meter block is made up of 64x64 
posts, a 16-meter block contains 16x16 posts and a 64-meter block has 4x4 posts. 

A tile, the largest element in the database, is a collection of blocks which always 
covers an area on the ground measuring 4096x4096 meters. A tile contains a 16x16 
arrangement of blocks regardless of resolution. 
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Figure 3.1: Pegasus Perspective Database 




































As shown in Figure 3.1, The Fort Hunter-Liggett (FHL) covers a rectangular area 
which consists of 56 tiles totally. The terrain data for 25 of them (white area in Figure 3.1) 
forms the actual database. Specifically, it covers 400 km^ area of FHL. This area is used for 
training purposes. 

Now, we can summarize the size information of a tile, a block and a post for 4 
different resolutions as follows: 

RESOLUTION POST SIZE BLOCK SIZE TILE SIZE 


1 meter 
4 meter 
16 meter 
64 meter 


32 bits 256 Kbytes 64 Mbytes 
32 bits 16 Kbytes 4 Mbytes 

32 bits 1 Kbyte 256 Kbytes 

32 bits 64 Bytes 16 Kbytes 


3. Post Structure 

Figure 3.4 shows how each post in the PVDB is packed and how the 32 bits are 
distributed among the elements: 



Figure 3.4: PVDB Post Structure 




The element infomiation is as follows: 

ELEMENT NUMBER MAXIMUM 

CODE OF BITS VALUE DESCRIPTION 


ELE 11 2047 

EL2 12 4095 

UCI 2 3 

NOR 4 15 

VGH 4 15 

VID 2 3 

NAT 1 1 

SSB 1 1 

GSV 6 63 

Each element has the following me 


Elevation, in meters 
Elevation, in half-meters 
Under Cover Index 
Surface Normal Indicator 
Vegetation Height Index 
Vegetation ID 
Nature 

Sun Shade Bit 
Gray Shade Value 

(see Figure 3.5): 


ELE: The bald tcirain elevation plus the vegetation height (in meters) above the 
lowest point in the database. At FHL the lowest point is sea level. 


EL2: Same as ELE except the units are in half-meters. 

UCI: The height, in meters, of a cultural feature above the ground (tree branches, 
eaves of buildings, etc.). 

NOR: A value which serves as an indication of the surface normal. 

VGH; Height of the cultural feature. The stored values of 0 to 15 indicate 
vegetation heights of 0 (water), 0 (grass), 1, 2,3,4, 5,8,10,15, 20, 25,30, 35,40, and 47 
meters. 
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VID: Indicates the cultural feature. This value is combined with UCI, NOR, 
VGH, and NAT to determine what a particular object is. 

NAT; If set to 1, this value indicates the cultural feature is natural, otherwise it is 
man-made. 

SSB: If set to 0, this post is shaded by another cultural feature. This value is time- 
dependent 

GS V: A linear set of values ranging from 0 to 63, where 0 indicates black and 63 

is white. 

B. LINE-OF-SIGHT CALCULATION 

Line-of-sight (LOS) is a central process in combat simulations that works at item 
level [Ref. 1]. The LOS algorithm is critical to the processes being simulated and impacts 
the run speed (ratio of game time to real time), since it may be the single most 
computationally expensive algorithm in simulation. Some LOS considerations in Janus 
have been simplified to increase computational efficiency. 

There are three general aspects of LOS processing [Ref. 1 :pp. 107-110]: 

1. LOS in support of detections. 

2. LOS through smoke and/or dust clouds. 

3. LOS supporting force deployment. 

For this thesis, we implemented the LOS calculation for the first aspect which is LOS 
in support of detections. A short description will be given for the other two aspects. 

1. Line-of-sight for Detection 

The first determination to be made is whether or not terrain features block the 
LOS between the observer and the target (see Figure 3.6). The process is as follows; 





- The direct line between the observer and the target is determined, its length 
calculated and it is divided into equidistant points. Each point is tested to 
determine if a terrain feature affects die probability of LOS (PLOS). 

- The number and the location of points on the line are determined as follows: 

- Compute the distance between the observer and the target (delta(X) and 
delta(Y)). 

- Determine N(X) and N(Y) by dividing delta(X) and delta(Y), 
respectively by the terrain grid size. Assign the larger of N(X) or N(Y) 
to Np, which is the number of points to be tested along the LOS line. 

- Compute dX = delta(X) / Np and Dy = dclta(Y) / Np. 

- Start at the observer’s position + (dx,dy) and determine the terrain height 
(ground elevation) of the grid in which that point rests. If the ground elevation 
is greater than that of the observer, LOS is blocked and the process is completed 
for that observer-target pair. 

- If the terrain height at that point is less than or equal to the height of the observer, 
add the height of trees/urban areas in that grid and recompute the terrain height. 
If the ground elevation + features height is greater than that of the observer, 
PLOS is decremented by the LOS degradation factor caused by features in the 
grid. 

- If the resulting PLOS is greater than 0.01, dx and dy are added to the old position 
and the process continues until LOS is considered blocked or the target position 
is reached. A random number is drawn and compared with the resultant PLOS 
to determine if acquisition has taken place. 

2. LOS Through Smoke/Dust Clouds 

If LOS exists between the target and the observer, the model checks to see if any 
smoke or dust blocks the LOS line. 
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3. LOS For Deployment 

The LOS for any unit can be displayed by the gamer from the workstation by 
packing the LOS block on the menu and then the unit The parameters of the LOS fan are 
attached to each unit, depending on its sensor (height, range) and how the orientation and 
width of the fan have been previously set by the gamer. 

C. WHY 1-METER RESOLUTION? 

To have reliable data that represents a terrain, there are some concepts that should be 
considered. First, we will describe these concepts with the help of Figure 3.5 and Figure 
3.7. 



Figure 3.7: General View of A Terrain 










The calculation of LOS is based on data stored in a grid of square cells. The elevation, 
the height of trees or urban buildings are stored as part of the terrain database and they are 
the factors which cause the unevenness of the terrain. 

In Figure 3.7, D represents the length of one side of square cells. and AX2 
represent the “absolute variation” which shows the unevenness of the terrain. H; and Hj 
represent the height values to be assigned to those square cells. 

The real height values are mostly expected to have some decimal digits. So, these 
values should be rounded by using a resolution value before being assigned to the square 
cells. We call this resolution value as “height resolution” and symbolize it as “AH”. 

The question at this moment is how we can choose the best AH. To answer this 
question, first we consider a flat terrain (see left cell in Figure 3.7)which means that A X is 
small. In this case, a small AH can be reasonable. But, when a rough terrain which has a 
big A X is considered (see right cell in Figure 3.7), a small A H will not work well. For 
example, assume we are using 10 centimeter height resolution when dealing with a terrain 
which has 10 meter of absolute variation. Using such a small height resolution i.e. 
sensitivity for an absolute variation which is relatively too high for that height resolution 
value will not give reliable rounded numbers for the real height values for the square cells. 
So, our first conclusion is as follows; 

Conclusion 1: The best idea is to equalize aH and AX or, to choose AH which 
is bigger than AX. 

Before applying the first conclusion to our problem, we should first normalize 
absolute variation and height resolution. Eq 3.1 and Eq 3.2 show this process: 

Normalized Terrain Variation = ^ (Eq 3.1) 

Normalized Height Resolution = ^ (Eq 3.2) 
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After normalizing process, we can approach to our problem more specifically as 
follows: 

We assume the reasonable normalized terrain variation for a man-made flat surface 
as about 0.5%, for a natural terrain as about 5% and for a rough terrain as about 50%. 

Since, The Fort Hunter-Liggett training area can be accepted as a rough terrain, then 
our second conclusion is as follows: 

Conclusion!: The normalized height resolution to be chosen should be around 

50%. 

Another important factor for our problem is the length of one side of a square cell, 
namely D. It is obvious that when D increases, AX will increase with a high probability 
since more elevation differences, more trees or more urban buildings will be inside the 
borders of one square cell. We believe that this situation should be avoided to have reliable 
height values for each cell. Because, we will use a constant height resolution value and a 
constant D for our all database and we should not increase the probability of having big 
values of AX by increasing D. So, our third conclusion is as foUows: 

Conclusion 3: For rough terrain databases the D value should be as small as it 

can. 

When we considered all of the concepts, factors and conclusions, we see that 1-meter 
resolution database with a 50 centimeter height resolution which has a 50% normalized 
height resolution is best to apply to our problem, and we believe that it represents The Fort 
Hunter-Liggett terrain very reliably. 
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IV. TRANSPUTER IMPLEMENTATION OF LINE-OF-SIGHT 
CALCULATION 


A. HARDWARE 

1. General 

The designed network of transputer implementation of LOS calculation consist of 
following elements; 

- An IBM PC as a host 

- An IMS B004 Evaluation Board inside IBM PC 

- An ALTA Remote TRAM Holder 

- An ALTA CTRAM-25-4F (with 1 T805 25 MHz transputer) 

- A SUN SPARC Station 

- An ALTA HSI/SBus inside SUN SPARC Station 

• An IMS BO 12 Evaluation Board 

- 16 ALTA CrRAM-25-4F (with 16 T800 20 MHz transputers) 

A general view of the network is shown in Figure 4.1. In section 2, each of tht 
network elements will be mentioned in detail. In section 3, the implementation wUl be 
described with the modifications made by us towards our design purposes. 

2. Background 

a. The TramputerlHost Relationship 

The transputer is normally employed as an addition to an existing computer, 
referred to as the host Through the host, the transputer application can receive the services 
of a file store, a screen, and a keyboard as shown in Figure 4.2. 

When the host is equipped with an add-in transputer interface board and the 
appropriate software, we call it a transputer development sys m. Presently, the host 
computer can be an IBM PC or compatible, a NEC PC, a DEC Micro VAX II, or a Sun 
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Figure 4.1: General View of the Implementation Network 





SPARC Station in transputer development systems. But with the current capacity of our 
laboratory we are able to use an IBM PC for our implementation. 



Figure 4.2: The Transputer/Host Relationship 


b. IBM PC As A Host 

The transputer communicates with the host along a single INMOS link. A 
program called a server [Ref. 15], executes on the host at the same time as the program on 
the transputer network runs. The server ensures that the access requirements of the 
application in terms of keyboard, screen, and filing are fully satisfied. All communications 
between the application running on the transputer and the host services (like screen, 
keyboard, and filling resources) take the form of messages. The standard transputer C, C++, 
Pascal, and Fortran development systems uses a server called afserver. The Occam toolset 
uses a server called iserver. 

The root transputer in a network is the transputer connecting to the host bus 
via a link adapter. Any other transputers in the network are connected together using 
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INMOS links, to the root transputer. A transputer network can contain any size and mix of 
transputer types. 

Transputer components form a unique hardware environment which is not 
immediately compatible with most existing personal computers (PC) or main frames upon 
which development work is accomplished. The IMS B004 evaluation board was designed 
to meet these needs by interfacing a transputer memory with an IBM type PC allowing the 
software developer to edit, compile and test software using the PC as a host. 

c. The IMS B004 Evaluation Board 

The IMS B004 board is logicaEy divided into three distinct parts [Ref. 16]: 

1. The transputer, with buffered links and one or two megabytes of RAM. 

2. The PC subsystem logic, which allows a program running on the 
Personal Computer to reset and analyze systems. 

3. The IMS C002 link adaptor, which interface to a parallel address/data 
bus, such as the one provided on the system expansion slots within an 
IBM PC. The link adaptor is accessed by a program running on the 
Personal Computer to transfer data to and from the transputer. This 
device can convert PC’s byte-wide parallel data into serial link data for 
the transputer links, and visa versa. 

These three distinct parts of the board are joined together by jumpers. The 
“Reset” jumper allows the PC subsystem to respond to addresses from the PC, and connects 
the transputer’s reset, analyze, and error signals to those controlled by the PC. The “Link” 
jumper connects the link adaptor to one of the transputer’s links, and allows the Link 
Adaptor to respond to addresses from the PC. Figure 4.3 shows a block diagram of the B004 
board which fits in a full length eight bit slot of an IBM PC [Ref. 17]. 

Before any program can be downloaded to a B004 board from a PC, two 
jumper sockets must be fitted correctly. The use of these jumpers allows more than one 
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B004 to be present within a PC, but allowing only one of them to respond to the Transputer 
Development System (TDS). 



Figure 4.3: IMS B004 Evaluation Board Block Diagram 


The board which has the jumpers fitted is designated the Master, and any 
number of other INMOS evaluation boards can be attached to this one via the links. Figure 
4.4 shows the rear edge connectors of the B004, looking from the rear of the board. As can 
be seen, there are two columns of pins, and these are grouped into sets of five, suitable for 
the five way sockets which terminate the various cables supplied. 

The link sockets are self explanatory. The Up, Down and Subsystem sockets 
are concerned with system control, initialization and error handling. The simplest way to 
use them is to connect the DOWN socket of the Master TDS board to the Up socket of the 



next board with the Reset cable, and then daisy chain the Down from each board to the Up 
of the next. This method ensures that when the TDS resets the first board, all others in the 
chain are also reset (see Figure 4.5). 




Figure 4.5: Daisy Chaning of the Subsequent Boards 





The B004 board 


uses a group of 5 way connectors, to simplify the location of 
the various leads for a system (see Figure 4.6). 



Pin 

b 

a 

1 

GND 

NC 

2 

(missing) 

(missing) 

3 

PCLinkOut 

NC 

4 

PCLinkIn 

NC 

5 

GND 

NC 

6 

NotLink 

NC 

7 

GND 

GND 

8 

(missing) 

(missing) 

9 

LinkOut 0 

LinkOut 1 

10 

LinkInO 

Linkinl 

11 

GND 

GND 

12 

(gap) 

(gap) 

13 

GND 

GND 

14 

(missing) 

(missing) 

15 

LinkOut 2 

LinkOut 3 

16 

Llnkln 2 

Linkln3 

17 

GND 

GND 

18 

(gap) 

(gap) 

19 

(gap) 

(gap) 

20 

(gap) 

^P) 

21 

(gap) 

feap) 

22 

PCNotReset 

SubsystemNotReset 

23 

PCNotAnalyse 

SubsystemNotAnalyse 

24 

PCNotErrar 

SubsystemNotError 

25 

GND 

GND(missing) 

26 

(missing) 

(missing) 

27 

NotSystem 

NC 

28 

UpNotReset 

DownNotReset 

29 

UpNotAnalyse 

DownNotAnalyse 

30 

UpNotError 

DownNotError 

31 

GND 

GND(missing) 

32 

GND(missing) 

GND(missing) 


Figure 4.6: The B004 Board Edge Connector Pinout 
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The NotLink (b6) and NotSystem (b27) are used in conjunction with the Link 
and Reset jumpers described previously. When these signals are at logic 0, they select the 
functions associated with either reset or link to respond to signals from the PC. 

d. ALTA CTRAM (Computation TRAnsputer Module) 

The ComputeTRAM (or CTRAM) [Ref. 18] consists of a circuit board with 
transputer, memory, and connective hardware which is plugged into a TRAM Holder from 
ALTATechnology or similar boards from INMOS. The CTRAM includes from 1 to 32 
Mbytes of DRAM and supports the IMS T80x transputer (with a chip floating point 
processor) or IMS T425 (integer only) transputers. A variety of processor speeds and 
memory speeds are available, providing users with a wide range of cost-effective compute 
modules. 

The CTRAM is the basic unit for computation in parallel processing 
applications. With its range of external memory configurations and processor speeds, the 
CTRAM is a versatile tool for the system designer or the system integrator. The end-user 
can find extra value from the CJTRAM by matching the configuration of each CTRAM with 
the needs of his application. This customization results in a tailored, economical mix of 
processors and memory configurations. 

CTRAMs may be connected to other transputer modules via its four 
transputer links to form a wide variety of topologies. 

The module pinouts and descriptions for CTRAM is shown in Table 4.1. 

e. ALTA Remote Tram Holder 

The Remote TRAM Holder [Ref. 19] may be mounted inside of a disk 
enclosure, or in a chassis suitable for holding disk drives and/or transputer modules. Figure 
4.7 shows the block diagram of an ALTA Remote Tram Holder. 
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TABLE 4.1: CTRAM MODULE PINOUTS AND DESCRIPTIONS 


Hn 

# 

Pin Name 

In/ 

Out 

Function 

1 

Link2out 

Out 

Link 2 output 

2 

Link2in 

In 

Link 2 input 

3 

VCC 


Power (+5V) 

4 

Link lout 

Out 

Link 1 output 

5 

Linklin 

In 

Link 1 input 

6 

LinkSpeedA 

In 

Transputer link speed selection A 

7 

LinkSpeedB 

In 

Transputer link speed selection B 

8 

Clockin 

In 

5MHz clock signal 

9 

Analyze 

In 

'IVansputer analyze 

10 

Reset 

In 

Transputer reset 

11 

notError 

Out 

Transputer error indicator (inverted) 

12 

LinkOout 

Out 

Link 0 output 

13 

LinkOin 

In 

Link 0 input 

14 

GND 


Ground 

15 

Link3out 

Out 

Link 3 output 

16 

Link3in 

In 

link 3 input 
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Figure 4.7: The Block Diagram of ALTA Remote Tram Holder 
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(1) Jumper Options. The jumpers in lcx:ation P8 are provided to allow a high 
depee of configuration connects Link 0 of Module 0 with external link 0. The pins are 
labeled as to module and the link, and contain an arrow pointing out of the LINKOUT 
signal towards the LINKJN signal. The user may insert jumpers to connect any external 
links. 

Jumper 11 is factory-set to 20 Megabits/Second. The link speed can be 
changed to 10 Megabits/Second as a second alternative. 

(2) External Links. The differentially-driven links on the module are 
connected via modular plugs and jacks. The modular connectors found at locations PI, P2, 
P3, and P4 correspond with XO, XI, X2, and X3 of the configuration area (P8). Those links 
can be connected to any available links in the TRAM SLOTs by jumpers or configuration 
modules. 

(3) TRAM SLOTs and Topology. There are four TRAM SLOTs on the 
motherboard, labeled SLOTO to SLOTS. They arc arranged such that only a single pair of 
links (between SLOTl and SLOT2) is committed (hardwired). All other links are brought 
out to the P8 configuration area. 

(4) System Services. The Remote TRAM may be used without connecting 
system services (Error, Reset, and Analyze) to the host. The board will assert RESET upon 
power on. However, in some instances, the user may wish to access system services from 
the host. Connector P5 contains the equivalent of UP system services and should be 
connected to the host Connector P6 contains the equivalent of DOWN services and should 
be connected towards the next module in the chain. The Error, Reset, and Analyze signals 
will be propagated UP and DOWN (depending upon the signal) properly to allow daisy- 
chaining of the system services. 
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The signals on P5 and P6 are as follows: 


PIN SIGNAL 

1 GROUND 

2 ERROR 

3 RESET 

4 ANALAYZE 

/. HSI/SBus 

The HSI/SBus [Ref. 20] is a single-slot SBus interface between the Sun 
SPARC Station and transputers. It provides a high-speed interface between the SBus found 
on a Sun SPARC Station and Transputers. 

The HSI/SBus is a 32-bit SBus slave interface for a Sun SPARC Station. The 
HSI provides system services and four bidirectional transputer links to external transputers, 
using modular connectors and twisted-pair telephone cables. The links are differentially 
driven using AT&T 41L/R series of drivers. The HSI/SBus board is a single slot printed 
circuit board which conforms to Sun Microsystem’s published standards for a single slot 
SBus card. Figure 4.8 shows the layout of the board and the locations of the major board 
components. 



Figure 4.8: The HSI/SBus Board Layout 
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The SBus interface provides an electrical connection between the host and 
external transputer modules. It provides four, bi-directional transputer links to external 
transputers, and provides a set of control signals (Reset, Analyze, and Error) which arc 
controlled by the driver on the SPARC Station host. 

When the interface is initialized, transputer boot code is loaded into the dual- 
ported RAM and the transputer is then booted from that RAM. The transputer then executes 
the boot code to perform the interface functions. 

Connections to external devices are made by using modular telephone handset 
jacks. Figure 4.9 shows the six jacks on the end of the HSI-card. 


Facing the back of the SPARC Station 



LINKO LINKl LINK2 LINK3 DOWN UP 


Figure 4.9: HSI-Card Link and Control Connections 
The four links from the host interface are designated LinkO, Linkl, Link2, and 

Links. 

Reset, Analyze, and Error signals are provided for both DOV.-’N and UP 
connections. The DOWN connector sends the Reset and Analyze signals to remote 
transputers. 

g. The IMS B012 Evaluation Board 

The IMS BO 12 [Ref. 21] is a curocard TRAM motherboard which is a member 
of a family of TRAM motherboards which have a compatible architecture. External signals 
enable it to control a subsystem of motherboards, or to be a component of such a subsystem. 


46 





The smallest TRAM is “size 1”. Each of the 16 sites for modules on the IMS 
BO 12 board accepts a size 1 module. Each module site, or “slot” has connections for four 
INMOS links which are designated link 0, link 1, link2, and link 3. TRAMs which are 
larger than size 1 can be mounted on the B012. A larger module occupies more than one 
slot and need not use all of the avaUable link connections provided by the slots which it 
occupies. 

The B012 has two IMS CXHM link switches. These devices are able to connect 
together links from the slots and 32 links which are available on an edge connector. The 
connections can be changed by control data passed to the board down a configuration link, 
which may come from some master system or from one of the TRAMs on the BO 12 itself. 

The B012 has two DIN41612 96-way edge connectors, PI and P2. These 
carry almost all signals and power to/from the board and are easily identified from the 
board silk screen printing and from Figure 4.10. P2 carries power, pipeline and 
configuration links and system control signals (reset, analyze, and error). 


Slotl 

Slots 

Slot9 

Slotl3 

SlotO 

Slot4 

Slots 

Slotl2 


Stot2 

Slot6 

SlotiO 

Slotl4 

Stot3 

Slot? 

SlotU 

SlotlS 


IMS B012 


PI 


P2 


Figure 4.10: IMS B012 Slot Potions 
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The link connections to the 16 slots are organized as foMows; 

Two links from each slot (links 1 and 2) are used to connect the 16 slots as a 
16-stage pipeline (in a pipeline, multiple processors are connected end-to-end as in Figure 
4.11). The pipeline is actually broken by jumper block Kl. Klwill usually be jumpered in 
the standard way to give a 16-stage pipeline but can allow other combinations. Figure 4.12 
shows the standard jumper configuration for Kl which connects all 16 TRAMs in a 
pipeline. 



Figure 4.11: A Module Pipeline 
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Link 1 on slot 0 is wired to an edge connector (P2) and is called PipeHead. 
Link 2 on slot 15 is also taken to P2 and is called PipeTail. By connecting the pipe heads 
and tails from multiple boards together, a large, multi-board pipeline is created. 

The other two links (links 2 and 3) of each slot are, in general, connected to 
two IMS C004 programmable link switches. The IMS C004 has 32 input pins and 32 output 
pins, plus an INMOS link (ConfigLink) used to send configuration information to the IMS 
0)04. Any of the output pins can be “connected” to any of the input pins, so a signal 
presented on the input pin would be buffered and transmitted on the output pin (with a slight 
delay). The switch connections are made according to information sent to the IMS €004 
down its ConfigLink. The two IMS C004s on the IMS B012 allow 64 link connections to 
be made under software control. 

The Reset, Analyze and Error pins of TRAMs (and transputers) is generally 
refeired to collectively as “system services”. The system service signals are used to reset 
TRAMs and transputers, to place transputers in an analyze state (for debugging) and to 
carry the fact that an error has occurred in one processor in an array back to some host 
system which will deal with the error condition. 

Some TRAMs and most evaluation boards are capable of generating the 
system services for other TRAMs and transputers. This is called a subsystem control 
capability. The IMS BO 12 can be connected to another board with subsystem control and 
also accommodate one TRAM with subsystem control. Furthermore, the IMS B012 can 
generate subsystem control signals for other boards. The system service signals are 
organized in such a way that, another boards can be daisy-chained by using Up and Down 
pins on P2. The logic here is same as it is for B004 boards. 

The IMS BO 12 has a six-way DIL switch (SWl) located between PI and P2. 
Each of the six switches make up SWl controls one signal on the board. When a switch is 
on, the signal is low and when the switch is off, the signal is high. So, the board link speed 
can be set to either 10 Mbits/s or 20 Mbits/s with these switches. 
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(1) PI Connections. Connector PI has three rows of 32 pins. All the pins in 
row “a” are connected to the ground. All the pins in row ‘b” are link inputs and all the pins 
in row “c” are link outputs. At each of the 32 positions along PI, the three pins from rows 
a, b and c cany one link. These signals may be connected to devices with link ports in any 
way the user desires. 

The link connections on connector PI arc intended mainly for 
communication between the IMS B012 and other boards in a card cage. However, it is also 
possible to use these PI links and the IMS C004 link switches to switch link connections 
for an external system. 

(2) P2 Connections. If the IMS B012 is to be used in an INMOS ITEM card 
cage, the ITEM supplies power and has a built-in back-to-back connector which allows link 
and reset cables to be connected to P2. Figure 4.13 shows the back-to-back conneaor pins 
as viewed from the rear, i.e. looking towards the pins. The boxes represent pluggcd-in 
cables. A good 5V power supply must be connected to the appropriate pins on P2. 




• 1-Power 

PipeHead-1 

0 [ 


, 1-PipeTkil 



r 



U L 

L 


Link Connections 




from Ki 


1 r 

1* 1-Subsystem 

Up-1 

ifl 




Figure 4.13: View of Back-to-back Connector Pins for B012 
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(3) IMS B012 as a Slave to a Master Controller. In a standard configuration 
where the IMS BO 12 is connected to a master-control system such as an IMS B004, 
PipeHead and ConfigUp links would be connected to two links on the host system, with 
“Up” system control port connected to the “Subsystem” port of the host (see Figure 4.14). 



Figure 4.14: The IMS B012 Board as a Slave 

(4) IMS B0I2 as a System Master. If a TRAM with “subsystem” capability 
is installed in slot 0 then the IMS B012 can act in a stand-alone or master role. With switch 
6 (on six-way OIL switch) off, the system control to the other modules on the board and the 
“Down” system control pins on P2 are driven from the subsystem pins on the TRAM in slot 
0 . 


3. Our Implementation 

The steps for our implementation can be summarized as follows: 

- To disable T414 transputer on the B004 board inside the PC host. 

- To set up a remote tram holder and to place our root transputer on it. 

- To connect Sun SPARC Station which has an HSl/SBus to the remote tram 


holder. 




- To place 16 T805 transputers on a B012 board and to connect B012 board to 
the remote tram holder and B004. 

- To set the link speed as 10 Mbits/second. 

(1) Disabling the T4I4 Transputer on the B004 Board. As we have seen in 
the section which is related with B004 board, only T414 transputer can be used as root 
transputer on a B004 board and we can have a total of 2Mbytes RAM. But for our 
application, with a purpose of having more memory and speed, it was decided to use a T805 
transputer as root transputer with a total of 4Mbytes RAM, namely an ALTA CTRAM-25- 
4F. So, the T414 transputer on the board, had to be disabled. 

To disable the T414 transputer on the B004 board, two connections were 
made between two different pin pairs on the edge connector. These connections arc shown 
in Figure 4.15. 

(2) Setting Up the ALTA Remote Tram Holder. PdXss disabling the T414 
transputer, an ALTA CTRAM-25 4F which is actually a 25Mhz T805 transputer and 
4Mbytes DRAM, was placed on slot 0 of the remote tram holder. So, this transputer became 
the root transputer. 

Since a Sun SPARC Station, a B004 board and a B012 board connections 
were planned for the remote tram holder, each of them had to be taken care of separately 
because of the different requirements. 

The HSl/SBus converts the Sun SPARC Smtion’s parallel data signals to 
serial data signals for the transputer links. The voltage for the produced signal varies 
between -15 and +15 AC. But, transputers require 5V DC voltage. TTris voltage conversion 
for the signals is normally done by the converter on the remote tram holder if the jumpers 
are used in the P8 Configuration Area. So, two jumpers were used in the P8 Configuration 
Area for the link between Sun SPARC Station and remote tram holder to allow the 
necessary conversion and to assign Link 3 of the root transputer to the Sun SPARC Station 
(see Figure 4.16). 
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Pin b 

a 


^ 1 GND 

NC 


2 (missing) 

(missing) 

1 

3 PCLinkOut 

NC 

Tram Holder 

4 PCLinkIn 

NC 

LinkO 

^ 5 GND 

NC 

6 NotLink 

NC 

7 GND 

GND 

8 (missing) 

(missing) 

9 LinkOut 0 

LinkOut 1 

10 Linkin 0 

Linkin 1 

11 GND 

GND 

12 (gap) 

(gap) 

14 (missing) 

(missing) 

15 LinkOut 2 

LinkOut 3 

16 Linkin 2 

Linkin 3 

18 (gap) 

(gap) 

19 (gap) 

(gap) 

20 (gap) 

(gap) 

21 (gap) 

(gap) 

22 PCNotReset 

SubsystemNotReset 

23 PCNotAnalyse 

SubsystemNotAnalyse 

To Remote 

24 PCNotError 

SubsysiemNotError 

Up 

25 GND 

GND(missing) 

26 (missing) 

(missing) 

27 NotSystem 

NC 

28 UpNotReset 

DownNotReset 

29 UpNotAnalyse 

DownNotAnalyse 

30 UpNotError 

DownNotError 

31 GND 

GND(missing) 

32 GND(missing) 

GND(missing) 


Figure 4.15: The B004 Board Edge Connector Pinout After Modification 






Figure 4.16: Remote Tram Holder 1% Configuration Area After 
Jumpering 

Because the PC’s parallel data signals are converted to serial data signals 
for the transputer links by the C002 Link Adaptor on the B004 board, we didn’t need the 
conversion which was done for the Sun SPARC Station signals. Then, the other 3 links 
Link 0, Link 1 and Link 2 of the root transputer had to be connected to the PC and BO 12 
board directly, without using jumpers in the P8 Configuration Area. But, the modular 
connectors P1-P6 (P1-P4 for transputer links, P5 and P6 for system services) have 
originally AT&T 41L/R series of drivers. So, those three links and UP and DOWN system 
services were carried to a connector which was located at the back of the remote tram 
holder and which had drivers for transputer link cables and for system service cables. For 
carrying links, two wires were used, one for LinkOut and one for Linkin signal (see Figure 
4.16). For carrying system services, three wires were used, one for Analyze, one for Reset 
and one for Error signal. Figure 4.17 shows the connections made inside the remote tram 
holder. 
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Figure 4.17: The Connections Made Inside the Remote Tram Holder 

After the connections were made inside the remote tram holder, the 16 
CTRAMs were placed on the BO 12 board and 16 T805-20 MHz transputers were placed on 
these CTRAMs. 

The fixed hardware configuration for all the transputers in the network can 
be checked with the program named “check”. This program runs in PC Host. Figure 4.18 
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shows the output of that “check” program for our application* and Figure 4.19 shows the 
physical view of our current fixed hardware configuration that we have for our transputers. 
We will see how a parallel application is created for a multi-transputer system with a fixed 
hardware configuration in the software part of this chapter. 


Transputer# 

LINKO 

LlNKl 

LINK 2 

LINK 3 

0 

HOST 

1:1 

2:2 


1 


0:1 

3:1 


2 


4:2 

0:2 


3 

- 

1:2 

5:1 


4 


6:2 

2:1 


5 


3:2 

7:1 


6 


8:2 

4:1 


7 


5:2 

9:1 


8 


10:2 

6:1 


9 


7:2 

11:1 


10 


12:2 

8:1 


11 


9:2 

13:1 


12 


14:2 

10:1 


13 


11:2 

15:1 


14 


16:2 

12:1 


15 


13:2 

16:1 


16 


15:2 

14:1 



Figure 4.18: The Output of “Check” Program for Our Application 


1. For example. Figure 4.18 first row shows the following connections for Transputer# 0 (root): Its 
Link 0 to Host, its Link 1 to Link 1 of Transputer# 1 and its Link 2 to Link 2 of Transputer# 2. 
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Figure 4.19: The Physical View of the Fixed Hardware Configuration 
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And finally we made the connections for Sun SPARC Station, 8004 
board, 8012 board and remote tram holder as shown in Figure 4.20 Figure 4.21 and figure 
4.22 (for 8004, refer to Figure 4.15). 

The slot 0 link 0 on the 8012 board usually needs to be connected to IMS 
C004s. This standard configuration reqi ? a connection to be made via P2. A single 
connector assembly (termed the “yellow link jumper plug") are used for this purpose. The 
position of the jumper is shown in Figure 4.22. 


Facing the back of the Sun SPARC Station 



LBSKO LINKl LINK2 LINK3 DOWN UP 



Facing the front of the Remote IVam Holder 



LINKO LINKl LINK! LINK3 DOWN UP 



Figure 4.20: The Connection Between Sun SPARC Station and Remote 
Tram Holder 






(3) Setting Up the Link Speed. Because of the B004 board’s speed 
limitation, we set up the link speed as 10 Mbits/sec. To set up link speed for the remote tram 
holder, we connected the jumper J1 with the center position and the position labelled “10”. 
For the B012 board, we set the DIL switches for links to operate at 10 Mbits/sec. 

The link speed set up for the Sun SPARC Station is made by running an 
independent program, before running the real application program. We will mention about 
it in the software section of this chapter. 



Figure 4.21: The Connections From the Back of Remote Tkam Holder 
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Figure 4.22: The Connections from the Back of B012 Board 



B. SOFTWARE 


1. General 

The elements of the system and their functionalities from the software side of 
view is shown in Figure 4.23. 

The main processes can be summarized in general as follows: 

- Tie link operations between Sun SPARC Station and Remote Tram Holder and 
setting die link speed as 10 Mbits/sec. 

- Loading the height data of the selected terrain from Pegasus Database to the 
CTRAMs. 

- LOS calculation between the start and goal points which are sent to Sun SPARC 
Station by a server which represents JANUS. 

- Sending the result back to the server from which the LOS calculation request is 

made. 

- The afserver task on PC. 

a. Installing HSIlBus and Setting the Link Speed 

As we have seen in the hardware part of this chapter, the HSl/Bus is a high¬ 
speed interface between the SBus found on a Sun SPARC Station md transputers and it 
provides link operations between them. [Ref.20] gives all the detailed information for 
installing and usage. 

The program which sets up the link speed between Sun SPARC Station and 
Remote Tram Holder was supplied by ALTA Technology Corporation upon the request of 
us. The link speed should be 10 Mbits/sec before executing the main program because of 
the speed limitation of the PC host. 
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Figure 4.23: The Elements of the System from Software Side of View 


b. Our Processor Farm Application 

Three things must be written to create a processor farm application 
[Ref. 12:p. 77]: 

1. A master task to split up the job into the independent work packets, i.e. sub¬ 
jobs. 

2. A worker task, which is automatically copied to each node of the network 
of transputers. 

3. A configuration file, describing the memory requirements and other 
attributes of the tasks. 
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(I) Master, Worker and Router Tasks. There is only one copy of the master 
task, and this is placed on the root transputer. A copy of the worker task is placed on every 
transputer in the network. 

Sp)ecial procedures are included in the run-time libraries of the Parallel 
languages to enable the communication between the master and the workers. They work in 
conjunction with another task, called the router. 

Normally, router task is not written by the user, but is automatically added 
to the processor farm. When the master has a sub-job to be done, it calls a procedure which 
gives details of the sub-job to the router. The router then finds a worker somewhere in the 
network which is currently idle, and sends the work packet to it. The worker task then 
processes the work packet, and when it has finished, it calls a procedure to send the result 
packet back to the router, which returns it to the master. 

For a normal processor farm application: 

- A worker task contains three sequences: read a packet, process it, send 
back a result packet (i.e. input, process, output). 

- Every worker should get the same input. 

- For every cycle those three sequences start from the beginning. 

But, for our application: 

- Since we have a big amount of map data, we should divide it to little 
portions and load them to different CTRAMs at a time. Our map is too big to be loaded to 
a CTRAM. So every worker has different input. 

- If we had used the same three sequences as mentioned above, we would 
have to load the whole data for every cycle. This would be too time consuming. So, we 
make first an initialization by loading the map data. Then, we send the point information to 
workers as input for LOS calculation, they process it and return the LOS result back. And 
for the second LOS request we don’t have to make initialization again. Just the second part 
that includes input, process and output sequences repeats. 
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Because of the differences which we just described, routing in our 
application is done with the programs written by us instead of being done automatically. 
The source files for master, worker and router tasks are listed in Appendix B. 

(2) Configuration File. The configuration file [Ref. 12:p. 38] describes the 
system to be built. It lists all the physical processors in the system, the wires connecting 
them, the tasks to be loaded into the system and their logical interconnections. In this 
section of the Chapter IV we explained configuration file giving the examples from our 
actual configuration file “btestlSO.cfg” which is listed in Appendix B. 

The first thing the configuration needs to describe is the hardware 
configuration between the processors. The following configuration file lines declares the 
processor in the host PC, the processor in the Sun SPARC station and three transputers 
including the root transputer and describes the actual physical cables between these 
processors for our application: 

processor host 
processor sun type=pc 
processor root 
processor pi 
processor pll 

wire ? root[0] host[0] 

wire ? root[l] pl[l] 

wire ? root[2] p2[2] 

wire ? root[3] sun[0] 

wire ? pl[2] pll[l] 

The PROCESSOR statement declares a physical processor. Every 
processor in the physical network must be declared, including the host processor from 
which the network is to be bootstrapped^ (normally an IBM PC-type machine). The 
configurer assumes that the processor named host is the host processor. In the case of an 


2. The linker program, linkt, normally produces an executable image file prefixed by a short 
bootstrap program which allows the the afserver to load the image into an empty transputer the 
bootstrap initialises the transputer and reads in the rest of the image file. 


64 





IBM PC host processor, the host will usually be executing the afserver program when the 
network is loaded, simply because that is the program which loads the rest of the network. 
It is necessary to be able to specify the afserver task to the configurer so that its ports can 
be connected to ports in user tasks, but without forcing the configurer to attempt to 
bootstrap the IBM PC. Similarly, some processors in the network might be set to bootstrap 
from ROM rather than from link. A processor is declared to the configurer as having 
already been bootstrapped by means of the “type” attribute. The default for the host is that 
it is “type=pc” already. For our application, the Sun SPARC station processor was also 
described as “type=pc”. 

The WIRE statement declares a physical wire connecting links on two 
physical processors. Each wire supports two connections, one in either direction. The two 
link specifiers in the WIRE statement may therefore be interchanged without affecting the 
statement’s meaning. Each wire is given a name (or *?’ can be used instead of a name if the 
name will not be referred later). The numbers in the brackets for the WIRE statements are 
the link numbers of those processors which are used for connection. The processor 
identifiers used in a wire statement must have been declared in a previous PROCESSOR 
statement. This is a general rule: all objects in the configuration language (processors, 
wires, tasks) must be declared before they are used. 

As well as describing the hardware of a system, the configuration file must 
contain details of all its software tasks and their interconnections. For each concurrently 
executing task in the system, the configuration file must contain a TASK statement. The 
TASK statement declares a task, which may be either a user-supplied task or one of the 
standard tasks provided with the configurer. The following configuration file lines declares 
the afserver task, filter task, master task, two router tasks and two worker tasks for our 
application: 
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task afserver 
task filter 
task master 


ins=l outs=l 

ins=2 outs=2 data=15k 

ins=5 outs=5 data=15k file="tr_commtb4" 


task routerO ins=20 outs=20 data=2k file="router.b4" urgent 

task routerl ins=20 outs=20 data=2k file="router.b4" urgent 


task workerOO ins=l outs=l data=275k file="worker.b4" 

task workerOl ins=l outs=l data=275k file="worker.b4" 


Each task declaration must include an “ins” attribute, which specifies the 
number of elements in the task’s vector of input ports and an “outs” attribute, which 
specifies the number of elements in the task’s vector of output ports. The “data” attribute 
specifies the amount of memory which a task needs. For example the filter task requires a 
minimum of 15 KByte of workspace. A user task for which no memory requirement is 
specified gets all the ftee memory remaining once any other tasks placed on that processor 
are loaded. Only one task on each processor can have its memory requirements left 
unspecified in this way. The configurer would otherwise have to decide how to split the 
remaining memory between several tasks with unspecified requirements: because an even 
split is unlikely to be desirable in practice, that is not allowed. The “urgent” attribute 
specifics that the task’s initial thread is to be started at the urgent priority level. The default 
is that the task’s initial thread is started at the non-urgent priority level. The “file” attribute 
specifies the file in which the memory image of the task is to be found. Task image files are 
produced by the linker program. The “file” attribute is ignored for the host processor and 
for any processor for which the processor attribute “type=pc” has been specified. 

The placement of tasks on processors is specified by the PLACE 
statement. It determines which processor a particular task is to execute on. Every task must 
be placed on some processor. The following configuration file lines describes the 
placement of the afserver task, filter task, master task, two of the router tasks and two of 
the worker tasks for our application: 
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place afserver 

host 

place filter 

root 

place master 

root 

place routerO 

root 

place workerOO 

root 

place routerl 

pi 

place workerlO 

pi 

The CONNECT statement establishes a channel between two tasks, by 

connecting an output port to an input port. Because channels (unlike wires) are 

unidirectional, two CONNECT statements are needed to create channels going in both 

directions between two tasks. The following configuration file lines describes the channels 

between the afserver task. 

filter task, master task, two router tasks and one router-one 

worker tasks for our application: 

connect ? afserver[0] 

filter[0] 

connect ? filter[0] 

afserver[0] 

connect ? filter[l] 

master[l] 

connect ? master[l] 

filter[l] 

connect ? inaster[2] 

router0[0] 

connect ? router0[0] 

master[2] 

connect ? routerO[l] 

routerl[0] 

connect ? routerl[0] 

routerOfl] 

connect ? router0[4] 

worker00[0] 

connect ? worker00[0] 

router0[4] 


The CONNECT keyword can be followed by an identifier naming the 
connection, but all the configuration statements which declare new identifiers allow a 
question mark to be used in place of the identifier being declared. This is useful when there 
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is no need to refer to an object after it has been declared. After the identifier (or question 
mark) the output port is coded first, and then the input port is coded. 

And, finally the BIND statement allows the contents of a port to be 
explicitly set to some literal value. Normally, ports are only bound by means of the 
CONNECT statement: ports left unbound are pointed at unique transputer channel words 
so that attempts to send or receive messages through them cause the minimum harm; the 
thread causing the attempt to communicate over the unbound port simply pauses 
indefinitely rather than causing failure of possibly all threads running on the processor. One 
application of the BIND statement is to give a task access to the transputer’s external event 
mechanism. This appears as a channel word at a specific address. Another application of 
the BIND statement is to pass an integer parameter to a user task. We used the first 
application and initialized the “input port 4” and “output port 4” of the master task to point 
to that channel words at the addresses which are shown in the following configuration file 
lines: 

bind input master[4] value=&8000001C 

bind output master[4] value=&^M)0000C 

The configuration files help to create a parallel application for a multi¬ 
transputer system with a fixed hardware configuration. For our application, the fixed 
hardware configuration was shown in Figure 4.19 of the hardware part of this chapter. Our 
configuration file btestlSO.cfg is listed in Appendix B and Figure 4.24 shows our multi¬ 
transputer system application i.e. current topology for transputers. 

c. Loading the Height Data 

The Pegasus Database has all the terrain height data, as we detailed in Chsq>ter 
in. Because of the memory limitations of CTRAMs (each of them has 4Mbyte RAM), we 
can read and load the height data for a limited area at a time. 
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In our application program, we use an 5120 x 2304m. terrain which includes 
the training area whose UTM coordinates are 54000 - 59000 WE and 78000 - 80000 SN 
and PVDB coordinates are 10692 - 15672 WE and 14096 - 16096 SN. TTiis area was 
selected because, its vegetation has the desired characteristics for a tank battle training. 

The loading process occurs in two basic steps. First, the data is read by the Sun 
SPARC Station from Pegasus Database and dien transferred (loaded) to CTRAMs. Pegasus 
Database is accessible through the Phoenix Server which is not a member of our department 
Local Area Network. However, the Pegasus Database was mounted through NFS (Network 
File System), so the database can be singly accessed by a read function. But, most of the 
time is still spent during this read function. The source code which we use for this data 
reading is listed in Appendix C. 

For the second part of loading process, if we call all data to be loaded to 
CTRAMs as map, every CTRAM will have a portion of that map in its own memory after 
loading. The speed of this transfer is 10 Mbits/sec and the transfer occurs through the links. 

The data are loaded to totally 15 CTRAMs. 14 of them are located on the 
B012 board and one of them is the on the Remote Tram Holder. Each CTRAM in our 
current system has a 4Mbyte memory. Since the router occupies some memory in each of 
them, we can load at most IS blocks (2S6Kbyte each) to one CTRAM. But, to use as many 
transputers as we can for efficient calculation and meanwhile to load those CTRAMs 
equally, we use 15 CTRAMs and each of them has 12 blocks. In each CTRAM, 12 blocks 
are loaded to 12 different workers. These workers are the smallest portions in which an 
LOS calculation occurs. Figure 4.25 shows the map we load at a time and the distribution 
of blocks to CTRAMs. 








2304m I 


TRANSPUTER 

WITH 12 
BLOCKS 


TRANSPUTER 

nil 

WITH 12 
BLOCKS 


TRANSPUTER 
1111111 
WITH 12 
BLOCKS 


TRANSPUTER 

2111 

WITH 12 
BLOCKS 


TRANSPUTER 
2111111 
WITH 12 
BLOCKS 


1536m 


TRANSPUTER 

1 

WITH 12 
BLOCKS 


TRANSPUTER 

Ill 

WITH 12 
BLOCKS 


TRANSPUTER 
111111 
WITH 12 
BLOCKS 


TRANSPUTER 

WITH 12 
BLOCKS 


TRANSPUTER 
211111 
WITH 12 
BLOCKS 


768m 


ROOT 

TRANSPUTER 
WITH 12 
BLOCKS 


TRANSPUTER 

11 

WITH 12 
BLOCKS 


TRANSPUTER 

mil 

WITH 12 
BLOCKS 


TRANSPUTER 

21 

WITH 12 
BLOCKS 


TRANSPUTER 
21111 
WITH 12 
BLOCKS 


0 1024m. 2048m. 3072m. 4096m. 5120m. 

Figure 4.25; The Map Size and the Distribution of Blocks to CTRAMs 
d. LOS CalculaHon 

The LOS calculation request between two points is made by a server that 
represents JANUS system. The information about the start and goal points is sent to Sun 
SPARC Station using the link communication established between them (the program 
which is used for this purpose is listed in Appendix A as client_main.C). Then, this 
information is broadcasted by the Sun SPARC Station to the transputers after receiving the 
point information. 

The LOS calculation is made in each of the transputers. Since each transputer 
knows the borders of its map portion, the transputers whose map portions don’t include the 
coordinates of those two points and of the line between them returns “0” as an answer 
automatically. The transputers whose map portions include the coordinates of those two 
points and of the line between them make LOS calculations for their map portions, and 
return “0” if LOS exists or“l” otherwise. Then all the answers from transputers are added. 
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and if the total is “0”, that means LOS exists between them, but if the total is greater than 
or equal to “1", that means LOS doesn’t exist between them. This answer is sent to the 
server that represents JANUS by way of Sun SPARC Station. 

e. The Afserver Task on Host 

The afserver task is an ordinary MS-DOS executable (.exe) file that runs on 
the PC. It loads executable .b4 files into the transputer and also acts as a file server, 
handling I/O requests made by the transputer. The afserver and the transputer execute in 
parallel and communicate via an Inmos link. The messages sent to the afserver are normally 
generated by the Parallel C-h- run-time library. It converts I/O operations into messages 
requesting the afserver to perform MS-DOS operations and then waits for the afserver to 
reply. 

In principle, the afserver task could be directly connected to the user program. 
In practice, a filter task is interposed between them. The filter mns in parallel with the 
afserver and the user task; it simply passes on messages travelling in both directions. The 
filter is required because sometimes the messages passed between the user program and the 
afserver are only one byte long and the revision chip cannot handle single-byte message 
transfers on its hardware links. The filter pads out 1-byte messages to 2 bytes to avoid this 
problem. The connections for afserver and filter tasks can be seen in btestl80.cfg 
configuration file which is listed in Appendix B. 
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V. EXPERIMENTAL RESULTS FOR LINE-OF-SIGHT 
CALCULATION 

A. PERFORMANCE ANALYSIS 

When a line-of-sight request is received by our system, the information about start 
and goal points is broadcasted to all transputers in the network. Since each transputer has 
height data for a different portion of all area, LOS calculations are done only by the 
transputers along the line between start and goal points. The advantage of parallelism for 
our application is that each transputer starts doing LOS calculations at the same time. So, 
when we neglect the time spent for communications between transputers, the total LOS 
calculation time for all transputers which participate the calculation should be equal to the 
time spent by the transputer which does maximum LOS calculations. 

The most important factor for measuring performance increase with our parallel 
system is the distance between the two points which are subjects to LOS calculation. If the 
distance between those two points is too short and only one transputer does the calculation, 
then this is the worst case and we have no performance gain when we compare with a one 
processor system. If the distance between those two points is maximum, which is equal to 
the diagonal of the simulation area, then this is the best case and the performance gain is 
Jn where n represents the number of processors (transputers). 

So, ideally the expected average gain after some number of consecutive LOS 
calculations will be: 

EXPECTED AVERAGE GAIN = ^ (Eq 5.1) 

And the expected average utility of the system will be: 

EXPECTED AVERAGE SYSTEM UTILITY = ^/n = ^ (Eq 5.2) 
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Since we used 15 transputers in our application, by using Eq 5.1 and Eq 5.2 we can 
say that the expected average gain of our system is = 1.936 and the expected 

average system utility is (l/iljls)) =0.129. 

B. THE RESULTS 

In order to test our transputer implementation of line-of*sight calculation, we had to 
run our program such that all calculations would be done by one transputer. Then we could 
directly make comparison and see the improvement. But this could be possible only if the 
points between which the LOS calculation was required were inside the map borders of that 
transputer module. Since CTRAMs had approximately 4 Mbyte of limited available 
memory and the total training area required approximately 46 Mbyte memory, it was 
impossible to do timing testing with one transputer. Then, we decided to use another Sun 
SPARC station^ with a large memory to hold all training area data in its memory. We made 
a modification to our application programs to run them on that Sun station as being a non- 
transputer or a non-parallel version. So, every LOS calculation was done by a single 
processor whatever the distance between start and goal points were. Then we could test our 
implementation by using the scale factor between transputer and that Sun station which will 
be described below. 

We used two different start and goal point pairs for testing. TTie height values for both 
pairs were entered as big numbers, so we were sure that there was line-of-sight between 
start and goal points. This was important to provide a full calculation time. Because, the 
LOS calculation algorithm stops and returns the answer when a bigger height data is 
encountered before reaching to the end point. This could take a very short time. But, when 
there is line-of-sight between two points, this means every data on the line is checked and 
a full time LOS calculation occurs. 

1. The Sun station we used was a SPARCsystem 630MP Model 120 with 128 Mbytes memory and 
two 40 MHz SPARC2 processois. Its performance was 25 MIPS and 4 MFLOPS for our 
application. This performance is almost twice of the performance of a SPARCstationl which 
features 20 Mhz clock speed, 12 MIPS and 2.5 MFLOPS. 
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For the first pair, the distance between start and goal points were selected such that 
the coordinates of the points remained inside the borders of one transputer module. The 
purpose here was to allow only one transputer to do LOS calculation in our transputer 
implementation and to get one transputer LOS calculation time. Meanwhile we used the 
same points to get the Sun station LOS calculation time. These results^ are shown in Table 
5.1 and Table 5.2. The comparison between two calculation times gave us the scale factor 
between transputer and Sun station: 


SCALE FACTOR 


TRTIMEI 

SUNTIMEl 


1.117 


For the second pair, the distance between start and goal points were selected as 
maximum (as the diagonal of the area). The purpose here was to allow as many transputers 
as we could to do LOS calculation in our transputer implementation. We also used the same 
points to get the Sun station LOS calculation time for a maximum distance. These results^ 
are shown in Table 5.3 and Table 5.4. Then, we simulated a transputer with enough 
memory to hold all map data by using the SCALE FACTOR, named that simulated time as 
SIMTRTIME2 and found the SPEEDUP RATIO for the best case of our implementation: 


SIMTRTIME2 = SCALE FACTOR x SUNTIMEl = 18.956 


SPEEDUP RATIO = 


SlMTRTIMEl 

TRTIMEI 


= 2.581 


2. Th^e timing results are for 100 consecutive LOS calculations of each point. 

3. These timing results are for 100 consecutive LOS calculations of each point. 
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TABLE 5.1: THE TIMING RESULTS OF TRANSPUTER VERSION FOR SHORT 
DISTANCE (LIMITED TO ONE TRANSPUTER) 


TEST 

NO 

START POINT PVDB 
COORDINATE 

END POINT PVDB I 
COORDINATE | 

LOS 

RESULT 

TIME (sec) 

1 

10672,14096 

11695,14683 I 

0 

5.995 

2 

10672,14096 

11695,14683 

0 

5.983 

3 

10672,14096 

11695,14683 

0 

5.974 


1 AVERAGE TIME = TRTIME1 =5.984 1 


TABLE 5.2: THE TIMING RESULTS OF NON-PARALLEL VERSION 
(SUN STATION VERSION) FOR SHORT DISTANCE 


TEST 

NO 

START POINT PVDB 
COORDINATE 

END POINT PVDB 
COORDINATE 

LOS 

RESULT 

TIME (sec) 

1 

10672, 14096 

11695,14683 

0 

5.250 

2 

10672,14096 

11695,14683 

0 

5.935 

3 

10672,14096 

11695,14683 

0 

4.877 

1 AVERAGE TIME = SUNTIMEl = 5.354 | 
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TABLE 5 J: THE TIMING RESULTS OF TRANSPUTER VERSION 
FOR MAXIMUM DISTANCE 


TEST 

NO 

START POINT PVDB 
COORDINATE 

END POINT PVDB 
COORDINATE 

LOS 

RESULT 

TIME (sec) 

1 

10672,14096 

15672, 16096 

0 

7.337 

2 

10672,14096 

15672,16096 

0 

7.356 

3 

10672,14096 

15672,16096 

0 

7.337 


1 AVERAGE TIME = TRTIME2 = 7.343 | 


TABLE 5.4: THE TIMING RESULTS OF NON-PARALLEL VERSION 
(SUN STATION VERSION) FOR MAXIMUM DISTANCE 


TEST 

NO 

START POINT PVDB 
COORDINATE 

END POINT PVDB 
COORDINATE 

LOS 

RESULT 

TIME (sec) 


10672,14096 

15672, 16096 

0 

17.028 


10672,14096 

15672,16096 

0 

17.226 


10672, 14096 

15672,16096 

0 

16.661 


1 AVERAGE TIME = SUNTIME2 = 16.971 | 
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The communication overhead slowed down the processing time of transputers. The 
ratio between the expected best case gain which was Jn and the SPEEDUP RATIO showed 
us the maximum communication overhead between the transputers. We found that we had 
33.3 percent of communication overhead as a maximum value for our system: 

MAXIMUM COMMUNICATION OVERHEAD = = 0.333 

The next step was to determine the average gain and the average communication 
overhead for the system. First, we had to find the average LOS calculation times for both 
transputers and the Sun station to do that. We kept the lower left comer of the map as the 
start point and used a random number generator to generate 50 different goal points for 
LOS calculations. We used these 50 pairs of points for our transputer system and for the 
Sun station. The results'* were as follows: 

AVERAGE LOS CALCULATION TIME FOR TRANSPUTERS = 6.541sec 

AVERAGE LOS CALCULATION FOR SUN STATION = 8.89sec 

Then, by using these two average time values and the SCALE FACTOR, we found 
the AVERAGE GAIN: 

AVERAGE GAIN = = 1.51g 


t. These timing results ate forlOO consecutive LOS calculations for each 50 points. 



And, the comparison of EXPECTED AVERAGE GAIN which was (Jn) /2 and the 
AVERAGE GAIN gave us the average communication overhead between the transputers. 
We found that we had about 21.5 percent of communication overhead as an average value 
for our system: 

AVERAGE COMMUNICATION OVERHEAD - GAIN \ ^ 

((Vi5)/2) ) 

Finally, we calculated the average system utility for our application: 

AVERAGE SYSTEM UTILITY = = 0.1012 
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VI. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 

This thesis was an effort to improve Janus combat simulation model in a distributed 
memory and computing environment using transputers and PEGASUS 1-meter resolution 
database. We have shown that line-of-sight (LOS) calculation can be done using a multi 
transputer system with some modifications in the processor farming idea. 

Due to the memory limitations placed on us by the Sun SPARC station^ that we used 
in our application, we had to place 12 worker tasks on each transputer in the network. The 
number of worker tasks could be less only if the Sun SPARC station could keep bigger map 
data in its memory during each data loading process to the transputers. Because of the big 
number of worker tasks, we had a high communication overhead which affected the 
performance of our application. 

Although the performance increase is less than the expected values, the timing results 
have shown that further significant improvements can be provided for LOS calculation 
time with faster transputers and a Sun SPARC station that has more memory. 

B. RECOMMENDATIONS FOR FURTHER RESEARCH 

The further research opportunities can be classified under the following main topics: 

1. Connection To Janus 

In ideal conditions, the line-of-sight calculation requests should be made by Janus 
system itself and the start and goal point information should be provided to Sun SPARC 
station. But Janus is not available in NPS Computer Science DepartriKnt yet After the 


1. The Sun SPARC station in our antlicalion (see Figure 4.23) is a SPARCstation IPX with 16 
MBytes memory. 



completion of setting up the Janus in our department, the future work will be providing the 
connections between our application and the Janus system and make them work together. 

2. INMOS T9(MM) Transputers 

The INMOS T9CK)0 [Ref. 6:p. 351] is the latest member of the transputer family. 
It is designed to provide far higher performance and greatly improved communication 
facilities. INMOS has used advanced CMOS technology to integrate a 32-bit integer 
processor, a 64-bit floating point processor, 16 Kbytes of cache memory, a communications 
processor and four high bandwidth serial communications links on a single IMS T9000 
chip. The IMS T9000 transputer excels in real-time embedded applications, delivering 
exceptional single processor performance and scalable multiprocessor capability. In 
addition to executing several instructions each cycle, the number of cycles required to 
perform many arithmetic and logical operations has been reduced from previous 
transputers by adding extra hardware. Because of its superior characteristics, IMS T9000 
should improve our system performance significantly. 

3. ALPHA AXP Farm Programming Environment 

Alpha AXP Farms which arc produced by Digital Equipment Corporation are 
another choice for distributed memory parallelism. They also provide tools and libraries for 
farms. These AXP Farms use DECchip 21064 (Alpha AXP microprocessor) which is the 
fastest microprocessor in the industry [Ref. 6:p. 351]. DECchip 21064 offers the highest 
available performance with a 400 peak operations per millisecond, a cache bandwidth of 
3.2 GB/s, controls up to 16 MB cache and a 64-bit design. Therefore we believe that the 
applicability of Alpha AXP Farms to our problem can be a future research area. 

4. Parallel Programming Support Environments 

A parallel programming environment is a collection of tools for automating part 
or all of the steps in writing a parallel program [Ref. 6:p. 351]. A variety of environments 
and tools have been proposed, prototypes constructed, and a few commercially available 



systems marketed to parallel programmers. Among these EXPRESS [Ref. 6:p. 351] and 
The HELIOS [Ref. 6:p. 351] are available in our laboratory. 

EXPRESS is a collection of routine calls that form a toolbox for writing 
distributed-memory parallel programs. The toolbox routines are used as built-in functions 
to distribute data among processors and coordinate processors during parallel program 
execution. EXPRESS has been implemented on Intel, Mark IQ, nCUBE, and transputer- 
based machines [Ref. 6:p. 351]. 

The HELIOS Parallel Operating System has been designed to run on parallel 
computers. Such computers contain processing units, and fast communication between the 
processors. Many such parallel computers are built using transputers, and Helios runs on 
these machines. However, Helios also runs on parallel computers built using processors 
other than transputers. 

So, another future research area is to check the applicability of these parallel 
programming support environments to our problem and to investigate how much 
improvements they can provide for us. 
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APPENDIX A - SUN SPARC STATION SOURCE CODE 


This appendix contains the source listings of the C++ code developed for the Sun 
SPARC station that is used in this thesis. They are stored in files as listed below: 

1. link.h 

2. hsilink.h 

3. los_coni.h 

4. los global.h 

5. map.h 

6. map_c.h 

7. map_s_com.h 

8. s_comm.h 

9. unix_conim.h 

10. vector.h 

11. map.C 

12. map_c.C 

13. map_s_coin.C 

14. s_comm.C 

15. vector.C 

16. manager.C 

17. client_niain.C 
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FILENAME.: link.h 


AUTHOR.; Dr. Se-Hung KWAK & Cem Ali DUNDAR 

DATE.: SejKember 1993 

DESCRIPTION.; Contains the descri{»ion of link communication functions which are written in C 

language. 


/* Writes “Count “ bytes from “Buffer” to the specified link. “Linkid” is a valid link identifier. 
‘Timeout” is a non-negative integer representing tenths of a second. A ‘Timeout” of zero is an infinite 
timeout. •/ 

extern “C” int WriteLink(int Linkid, char* Buffer, int Count, int Timeout): 

/• Reads “Count” bytes into “Buffer” from the specified link. */ 
extern “C” int ReadLink{int Linkid, char* Buffer, int Count, int Timeout); 

/* Ready the link associated with “Name”. •/ 
extern “C” int OpenLink(char* Name); 

f* aoses the active link “Linkid”. •/ 
extern “C” int CIoseLink(int Linkid); 








FILENAME.: hsiKnk-h 

AUTHOR.: Dr. Se-Hung KWAK & Cem AM DUNDAR 


DATE.: Septemba-1993 

DESCRIPTION.: Header file which provides the necessary library functions for link 



/• @(#) Module; hsilink.h, revision 1.0 6/2/92 */ 
tinclude <sysfloccom.h> 

#defme h ‘h’ /* the h actually means nothing as used here */ 

/• 

* VO controls 

•/ 

struct HSI_SE1T ( 
unsigned int op; 16; 
unsigned int val;16; 

1 ; 

union HSIJO ( 
struct HSI_SETF set; 

); 

#define RESET (1) 

#(lefme ANALYSE (2) 

#define SETTIMEOUT (3) 

#derme TESTERROR (4) 

#denneTESTREAD (5) 

#define TESTWRTIE (6) 

r 

• _IOW write instructions to the kernel within the 

* ioctl command code. 

•/ 

#defme SETFLAGS JOW(h. 1, union HSIJO) 

/* 

• Endof hsilink.h 
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/*••*•***•••••♦** 


FE.ENAME 

.: los com.h 

AUTHOf 

Dr e-Hung KWAK&CemAliDUNDAR 

DATE. 

pt mber 1993 

DESCRIPnON 

.: Header file for two structs. One of them is for information about map and the 
outer IS for information about two points in the area 


#ifndefLOS_COM_H 

#derineLOS_COM_H 


#include “vector.h” 

/• Contains the lower left comer coordinates, the size and the grid size of map portion which is sent to 
transputers at a time. */ 
struct MAP_INFO( 
int start_x, start_y, size_x, size_y; 
double grid_size; 

I; 


/* Contains two vectors which have the information of two points between which LOS calculation is 
made. •/ 

struct CMD_INFO{ 
vector start, goal; 


#endifLOS_COM_H 
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FILENAME.: los_global.h 

AUTHOR Dr. Se-Hung KWAK & Cem Ali DUNDAR 

DATE September 1993 

DESCRIPTION.: Defines three global values used in the program. 


/* Defines that the size of a map portion which is sent to transputers at a time is 256m.x256m. */ 
#define MAP_SIZE 256 


/* Defines that the grid size showing the resolution is Im. */ 
#define GRID_SIZE 1.0 


/* It is assumed that the beginning and end points of a line in the area are 10m. above the terrain.*/ 
Kdefine AGENT_HEIGHT 10.0 
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FE^NAME. 

AUTHOR. 

DATE. 

DESCRIPTION. 


.: map.h 

.: Dr. Se-Hung KWAK & Cem Ali DUNDAR 

.: SejKetnber 1993 

.: Header file for the declarations of the class and the map class functions. 


#ifndefMAP_H 
Sdefme MAP_H 
#include “vector.h” 


class map | 
struct m£5)_tBp{ 

int start_x, stait_y, size_x, size_y; 
double grid_size; 
int* data; 
int refs; 

map_rep() lrefs= 1:1 


map{); /* Constructors */ 

map(int start_x4nt start_y,int si2e_x4nt size_y.double grid_size4nt* data); 

m^(const map& map); [* Copy constructor */ 

map& operator=(const map& map); /* Assignment operator */ 

~map(); 

/• Gets the lower left corner coordinates, the size and the grid size information of map. •/ 

int get_start_x() {return p->start_x;); 

int get_start_y 0 (return p->start_y;); 

int get_size_x() {return p->size_x:); 

int get_size_yO {return p->size_y;); 

double get_grid_sizeO {return p->grid_size;|; 

int* get_data() {return p->data;); 

vector to_map_coord( vector loc); 
int higher_than(vector& loc); 
int terrain_height(int& grid_x, int& grid_y); 
int map_post(int grid_x, int grid_y); 

1; 


#endifMAP_H 










map_c( int stan_it, int start_y, int size_x. int size_y, double grid_size); 
map m^_c_lo_mapO: /* only x,y are used */ 


#endifMAP_C_H 
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FE-ENAME.: map_s_com.h 

AUTHOR.: Dr. Se-Hung KWAK & Cem Ali DUNDAR 

DATE.: September 1993 

DESCRIPTION.: Header file for the source code written for sending the map pwtions to 


transputers. 


#ifndefMAP_COM 
#define MAP_COM 

#include “los_com.h" 

#include “map_c.h” 

#include “s_comm.h” 

cte map_s_comi 
MAP_INFO map_info; 
public: 

map_s_com(){ 1; 

void map_send{int n_lr, int tt_pro, map& map, s_comm& s_comml); /* Sends map portions. */ 

1: 

#endifMAP_COM 
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_comm.h 


FMNAME 

AUTOOR Dr, Se-Hung KWAK & Cem Ali DUNDAR 

DATE September 1993 

DESCRIPTION.; Header file for the source code which performs the link communication between 

SUN station and the transputers. 


finclude “link.h” 

#include "hsilink.h” 

#ifndefS_COMM_H 

#defmeS_COMM_H 

const int ROUTER_INrr = 1; 
const int SEND » 2; 
constintBCAST = 3: 
const int LISTEN = 4; 
const int TERMINATE = 5; 

class s_comm ( 
int outJink_num; 
intinjink_num; 
int outjink: 

s_commO (); 

s_comm(int out_Iink_numl, int in_link_numl): 

~s_coiiim(){ CloseLink(outJink): CloseLink(in_link);): 

int routerjnitfint num_tis, int* Its, int* undets. int* ps, int timeout); 

int sendfint dst, int nts, int size, char* buf, int timeout); /* Plain send. */ 

int send_i(int dst, int nts, int size, char* buf, int timeout); /* Send integers. */ 

int bcast_d(int size, char* buf, int limeoutf); /* Send doubles (byte convert). */ 

int listen(int timeout); /* Byte conversion. */ 

int terminaieCint timeout); 

/* Conversion functions for little-indian(transputer) and big-indian(SUN) problem. */ 
void convert4(char* buf 1, char* buf2); 
void convert_i_anay(int* buf 1, int* buf2, int size); 
void convett8(char* buf 1. char* buf2); 
void convert_d_artay(double* buf 1, double* bufZ, int size); 

); 


#endif S_COMM_H 






FD-ENAME.: unu_coffim.h 

AUTHOR.: Dr. Se-Hung KWAK & Cem Ali DUNDAR 

DATE.: September 1993 

DESCRIPTION.: Header file for dte link communication functions between two SUN Stations. 


#define SERVERJ>ORT_NUMBER 1053 
#define CLIENT_PORT_NUMBER 1053 

/* Link communication functions from “C libcaiy” for sender */ 
extern “C" int open_stream_s (int port_number): /* Opens link •/ 
extern “C" int send_buf_s(char* buf, int size): /* Sends buffer */ 

extern “C” int receive_buf_s(char* buf, int* sirep); /* Receives buffer •/ 
extern “C” int close_stream_s (void): /* Closes link •/ 

/* Link communication functions from C libraiy’Tor receiver. */ 
extern “C” int open_stream_c (char* host_name, int pott_number): /* Opens link */ 
extern “C" int send_buf_c(char* buf, int size); /* Sends buffer */ 

extern “C” int tieceive_buf_c(char* buf, int* skep); /• Receives buffer */ 

extern “C" int close_stteam_c (void): /* Closes link */ 
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double x,y,z; 
vector(); 

vector(double xl, double yl, double zl); 

double get_x() (return x;); 

double get_yO (retunj y;); 

double get_zO Iretum z;); 

friend int operatoi»»(vector vl, vector v2); 

friend vectoroperator+(vectcr vl, vector v2); 

friend vector operator-(vector vl, vector v2): 

friend vector operator*(double a, vector vl); 

double dotptodCvector vl); 

double magnitude(void); 

vector nonnalize(void); 

}; 

#endifVECTOR_H 
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FILENAME.: map.C 

AUTHOR.: Dr. Se-Hung KWAK & Cem Ali DUNDAR 

DATE.; September 1993 

DESCRIPTION.: This source code defines the map class functions. 


#include “map.h” 

map; :mapO /* Constructor */ 


p = new map_rep; 

p->start_x = 0; p->start_y = 0; p->size_x = 0; p->size_y = 0; 
p->grid_size = 0.0; 
p->dala = 0; //null pointer 

1 

map:;mi^int start_x4nt start_y,mt size_x4nt size_y4iouble grid_size4nt* data) /* Constructor */ 
p = new map_tBp: 

p->stait_x = start_x: p->stait_y = start_y; 
p->size_x » size_x: p->size_y = size_y: 
p->grid_size * gtid_size; 
p->data K riata; 

) 

map::msq)(const map* map) /* Copy constructor */ 

{ 

map.p->refs++; 
p = map.p: 

} 

map& map;:operator=(const map& map) /* Assignment tqieiator */ 

1 

map.p->refs++; 
if (-p->refs = 0) { 
delete!] p->data; 
delete p: 


I 
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map::~map() /• Destructor ♦/ 

I 

if(-<p->refs)==0)( 
deleteD p->data; 

) 

) 


vectw map::to_map_coord(vectOT loc) 

1 

vector map_offset(((double)p->stait_x)*p->grid_size, 
((double)p->start_y)*p->grid_size,0); 
vector loc_wrt_map = loc - map_offset; 
return (loc_wit_m^); 


int map::higher_than(vector& loc) 

I 

int giid_x = (int) ((loc.get_xO - p->start_x*p->grid_size)^>grid_si2»); 
int giid_y «(int) ((loc.get_y() - p->start_y*p->gri<l_size)y)>->grid_size): 
int height = p->daia[grid_y*p->size_x+grid_x]: 
return ((doubIe)i]etTain3eight(grid_x,grid_y) > loc.get_zO); 

1 

int map::terrain_height(int& grid_x, int& grid_y) 

{ 

return map_post(grid_x,grid_y); 

1 


int map::map_post(int grid_x, int grid_y) 

( 

I* index = size_y*gridJoc.x + gridjoc.y; */ 
index = p->size_x*grid_y + grid_x; 
return p->data[index]; 

) 
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FttJENAME.: map_c.C 

AUTHOR.: Dr. Se-Hung KWAK & Cem Ali DUNDAR 

DATE.; September 1993 

DESCRIPTION.: This source code constnKts a map portion to be send to transputers at a time. 


#include <iostream.h> 
tinclude <fstream.h> 

#include <stdio.h> 

#include “PVG_DEC.H” 

#include “PVG_DEF.IN” 

#include <pvdb.h> 

#include “map_c.h” 

/• Reads one block of terrain data to a buffer and then loads elevation data to data array of map portion 
by using the data in the buffer. •/ 

map_c::map_c(int stait_x, int start_y,int size_x, int size_y, double grid_siie) 


p - new map_iep; 
p->stait_x = start_x: 
p->start_y = start_y; 
p->size_x = size_x; 
p->size_y = size_y; 
p->grid_size « grid_size: 
p->data = new int[size_x*size_y]: 

/• One block of Im. resolution terrain data is read to a buffer here. */ 
get_terr(RESOLUTION_l,start_x,stait_y, 1); 

/* 65536 elevation data is loaded to data array of map portion here. •/ 
for(i=0:i<65536;i++)( 

p->data[i]=PVDB_UNPACK_ELE(TERRAINl[l][i]); 


f* Converts map_c class to map class. •/ 
map map_c::map_c_to_mapO 
1 

map mapl(p->stait_x,p->statt_y ,p->size_x,p->size_y,p->grid__size,p->data); 
retuni(mapl); 

) 
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FILENAMfc.: map_s_cotn.C 

AUTHOR Dr Se-Hung KWAK & Cem AM DUNDAR 

DATE September 1993 

DESCRIPTION.: This source code is for sending one map portion to transputers through the link 



tinclude “map_s_com.h" 
#include <iostream.h> 


void map_s_com::map_send(int n_ir, int n__pro, map& map, s_comm& s_comml) 

I 

MAP_INFO m^Jnfo, map.infol; 

map_info.start_x = map.p->start_x; 
map_info.stait_y = map.p->stait_y; 
map_info.size_!t = inap.p->size_x: 
map_info.size_y * map,p->size_y; 

/* Converts double, 

solves little_indian(transputer), big_indian(sun) problem, 
sends header, 

converts start_z, start_y, size_x, size_y ♦/ 
s_eomml.convert_i_airay((int*)&map_info,(ini*)&map_infol,4); 
double X = m^.p->grid_size; 
double y: 

s_comml.convert8((char*)&x,(char*)&y); 
map_infol.grid_size = y; 

s_comml.send(n_ir, njiro, sizeof(map_infol), (char*)&map_infol,SO): 

!* Sends real data (integer is 4 chars) */ 

s_comml.send_i(n_lr, n_pro, map_info.size_x ♦ map_info.size_y * 4,(char*)(map.p->data),50); 
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FILENAME.; s_comm.C 

AUTHOR.: Dr. Se-Hung KWAK & Cem Ali DUNDAR 

DATE.: September 1993 

DESCRIPTION.; This source code is for performing link communication between SUN station and 

transputers. It also has conversion functions for solving the little- 
indian(transputer) and big-indian(SUN) problem. 


#include <iostream.h> 
finclude “s_comm.h" 

/* Opens link. */ 

s_comm::s_comm(int out_link_numl, int in_link_numl) 

( 

out_link_num = out_link_numl; 
in_link_num = in_link_numl; 

cbar link_str[2]: 

link_str[0]= chat<out_link_numl): 

link_str[l] = ‘M)’; 

ouUink - OpenLink(link_str): 

if(out_link_numl !=in_Iink_numl) { 
link_str[0]= char(in_link_numl): 

Unk_str[l] = 

inJink » OpenLink(link_str):) 
else 

inJink = outjink; 

) 

/* Does router initialization for transputers. */ 

int s_comm::router_init(int num_trs, int* trs, int* unders, int* prs, int timeout) 

I 

int code = ROUTER_INIT; 
int val; 

convett4((char*)&code, (chai*)&val): 
if (WriteLink(out_link, (chat*)&val, sizeof(int), timeout) < 0) 
renim -1; 

convert4{(chat*)&num_tts, (cbar*)&val): 
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if (WriteLink(out_link, (char*)&val, sizeof(int), timeout) < 0) 
int* vals: 

vals = new int[num_tis]: 
convert_i_anay(trs, vals, num_trs); 

if (WriteLink(out_link, (char*)vals. sizeof(int)*num_irs, timeout) < 0) 
convert_i_anay(unders, vals, num_tis): 

if (WriteLink(out_link,(char»)vals, sizeof(int)*num_trs, timeout) < 0) 
conveft_Lairay(prs, vals, num_tis): 

if {WriteLink(out_link, (char*)vals, sizeof(int)*num_trs, timeout) < 0) 


/* Plain sending. No conversion. */ 

int s_comm::send(int dst, int nts, int size, chsu* buf, int timeout) 

{ 

int code = SEND; 
int val; 

convert4((char*)&code, (char*)&val): 
if (WriteLink(out_link, (char*)&val, sizeof(int), timeout) < 0) 
return O, 

convert4((char*)&dst, (ehar*)&val); 
if (WriteLink(out_linlc, (char*)&val, sizeof(int), timeout) < 0) 
return 0; 

convert4((chai*)&nts, (chai*)&val): 
if (WriteLink(out_link, (char*)&val, sizeof(int), timeout) < 0) 
return O, 

convett4((char*)&size, (char*)&val); 
if (WriteLink(outJmk, (char*)&val, sizeofCint), timeout) < 0) 
return 0; 

//No conversion. Send buf directly 
if (WriteLink(out_link, buf. size, timeout) < 0) 


1 
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f* Sends integers. •/ 

int s_coinm::send_i(int dst, im nts, int size, char* buf, int timeout) 

1 


convert4((chai*)&code, (char*)&val): 
if (WriteLink(out_link, (char*)&val, sizeof(int), timeout) < 0) 
return 0; 

conven4((chai*)&dst, (char*)&val); 
if (WriteLink(out_link, (char*)&val, sizeof(int), timeout) < 0) 
return 0; 

convert4((char*)&nts, (char*)&val); 
if (WriteLink(outJink, (chai*)&val, sizeof(int), timeout) < 0) 
return 0; 

convett4((cha)r*)&size, (char*)&val); 
if (WriteLink(outJink, (char*)&val, sizeoffint), timeout) < 0) 
return 0; 
char* vals; 

vais = new char[size]; 

convertJ_array((int*)buf, (int*)vals, size^izeoffim)); 
if {WriteLink(out_link. vals, size, timeout) < 0) { 
deleteD vals; 
return 0:) 
else! 

delete[] vals; 
return 1;|; 

I 

/* Sends doubles. ♦/ 

int s_comm:;bcast_d(int size, char* buf, int timeout) 

( 

int code = BCAST; 
intval; 

conv«t4({char*)&code, (char*)&val); 
if (WriteLink(out_link, (char*)&val, sizeoffint), timeout) < 0) 
return 0; 

convert4((chai*)&size, (char*)&val); 
if (WriteLinkfoutJink, (char*)&val, sizeoffint), timeout) < 0) 
return 0; 
char* vals; 
vals= new char[size]; 

convert_d_array((double*)buf, (double*)vals. size/sizeof(double)); 
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if (WriteLink(outJink, vals, size, timeout) < 0) 
return 0; 


/* Reads the value coming from transputers. •/ 
int s_comm::lisien(int timeout) 

( 

int code = LISTEN; 
int val, result; 

convert4((char*)&code, (char*)&val); 
if (WriteLink(out_link, (char*)&val, sizeofrint), timeout) < 0) 
return 0; 

if (ReadLink(in_link, (chat*)&val, sizeofrint), timeout) < 0) 
return 0; 

conveit4((char*)&val,(char*)&result); 
return result; 

) 

int s_comm::terminaie(int timeout) 

i 

int code = TERMINATE; 
int val; 

conven4((char*)&code, (char*)&val); 
if (WriteLink(out_link, (char*)&val, sizeofrint), timeout) < 0) 
return 0; 

1 

I* CONVERSION FUNCTIONS FOR LITTLE-INDIANCrRANSPUTER) AND BIG-INDIAN(SUN) 

PROBLEM STARTS HERE. */ 

void s_comm::convert4(char* bufl, char* buf2) 

{ 

buf2[3] = bufl[0]; 
buf2[2]-bufl[l]; 
buf2{l]-bufl[2]; 
buf2[0] = bufl [3]; 

) 
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void s_coinm::convertJ_array(iiit* bufl, int* buf2, int size) 


{ 

for (int i=0; i<size: i++) 

convert4((char*)(&(bufl[i])),(char*X&(bu£2[i]))); 

} 

void s_comm::convert8{chaf* bufl,char* buf2) 

{ 

buG[7] = bufl[0]: 
buf2[6] = bufl[l]; 
bu£2[5] = bufl[2]: 
buf2[4] = bufiP]: 
buf2[3] = bufl[4]: 
buf2[2] = bufl[5]; 
buQ[l] = buflt6); 

buf2[0] = bun[7]; 

1 

void s_comm::convett_d_aiTay (double* bufl. double* buf2. im size) 

( 

for (int i^; i<size; i++) { 
convert8((char*)(&(bun[i])),(char*)(&(buf2[i]))): 






FE-ENAME.: vector.C 

AUTHOR.: Dr. Se-Hung KWAK & Dan Ali DUNDAR 

DATE.: September 1993 

DESCRIPTION.; This source code deflnes the vector class operations. 


tinclude “vector.h” 

#includc <math.h> 

vector;:vector<) (x=0.0; y^.O; 2=0.0;); 

vectDn:vector(double xl, double yl, doublezl) {x=xl; y=yl; z=zl;); 
int operator=(vectM- v 1, vector v2) 

retum((vl.x==v2.x) && (vl.y=v2.y) && (vl.z==v2.z)); 


vector operator+(vector vl, vector v2) 

( 

vector v(vl.x+v2.x, vl.y+v2.y, vl.z+v2.z); 

) 

vector operator-(vector vl, vector v2) 

1 

vector v(vl.x-v2.x, vl.y-v2.y, vl.z-v2.z); 

) 

vector operator*(double a, vector vl) 
vector v(a*vl.x. a*vl.y, a*vl.z); 

) 

double vector;:dotprod(vector v2) /• Dot product •/ 

( 

ietum(this->x*v2.x + this->y*v2.y + this->z*v2j!); 
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double vecton:iTiagnitude(void) 


{ 

retuin(s<|rt((*this).do(prod(*this))); 

) 

vector vector:nonnali2e(void) /• Vector normalization •/ 

( 

vector result; 

double mag = (*this).magnitudeO; 
if (mag < lE-100) { 
resulLx = 0.0; 
result-y = 0.0; 
resultz = 0.0;) 
else ( 

result = (1.0/mag) * (♦this); 

1 

tetum(result); 
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FE-ENAME.: manager.C 

AUTHOR.: Dr. Se-Hung KWAK & Cem Ali DUNDAR 

DATE.; September 1993 

DESCRIPTION.: This is the main program. The number of transputers, workers and task 


distribution are defmed here. The user is asked to enter the lower left comer 
coordinates of the 512(hn.x2304m. map area first Then after loading of the 
whole map to tran.sputers, tlie information about the two points in the area 
between which LOS calculation will be made is expected to be entered and sent 
from another server via the communication link established between them. This 
information then is sent to the transputos and the result is expected fixim them. 
When the result Ls received, it is sent to the station from which the point 
information ccmes. This procedure can be repeated as many as the user wants. 



/* THIS VERSION OF MANAGERC IS FOR 15 TRANSPUTERS, THERE ARE 180 WORKERS. •/ 

#include <iostream.h> 

#include “unix_comm.h” 

#include <fstreain.h> 

#include “los_com.h” 

#include “map_s_com.h” 
finclude “los_global.h” 

#include “map_c.h” 

#defme NUM_OF_WORKERS 180 /* Each transputer has 12 workers. */ 

int org_x, «g_y, orgl_x, orgl_y; 
int x_counter, y_counter, tr_x, tr_y: 
float info[6]; 
int size; 

ifstream source; 
flcat los_iesult; 

vector agent(0,0AGENT_HEIGHT); 
double a.b,c jt,y,z; 
int addr = 0; 
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int main(void) 

( 

s_comiii s_comml(0,0); // output link and input link 
/* Total number of transputers. •/ 
const int totaljjrs = 15; 

/* Total numbw of workers. •/ 
const int toial_n_pr=: 180; 

/* Names of transputers. •/ 
static int trs[totaljHs] = { 

0.1.2.1Ul.ni.211,lin.2111.1111Ullll,lllllUlllll,lllini,2111111|; 
/* The number of children for each transputer for the current topology. */ 
static int undets[iotal_prs] = (2,1,1,1.1,1,1,1,1.1,1,1,1,0,01: 

/* The number of woAets for each transputer. •/ 

static int prs[total_prs] = (12,12.12.12,12.12.12,12,12.12,12,12,12.12.121; 

/* The distribution of woikers to transputers. */ 
static int n_ttltotal_n_pr] = ( 

0 , 0 , 0 , 0 . 0 . 0 , 0 . 0 , 0 , 0 . 0 , 0 . 

1.1,1,1,1.1.1.1,1,1.1,1, 

2.2.2,2,2.2.22,2.2.22, 

11,11,11.; 1,11.11,11,11,11.11,11,11. 

2121.21,21,2121212121212121. 

111 , 111 . 111 , 111 , 111 , 111 , 111 , 111 . 111 , 111 , 111 , 111 . 

211211211211211211.211211.211.211,211211. 

1111,1111.1111.1111.1111.1111.1111.1111,1111.1111.1111,1111. 

21112111.2111.211121112111,2111,211121112111.2111.2111, 

11111 , 11111 . 11111 , 11111 , 11111 . 11111 , 11111 , 11111 . 11111 , 11111 , 11111 . 11111 . 

2111121111,2111121111,2111121111.211112111121111211112111121111, 

111111.111111,111111,111111.111111,111111.111111,111111, 

111111,111111,111111,111111, 

211111211111211111.211111211111211111,211111211111. 

211111,211111211111.211111. 

1111111.1111111,1111111,1111111,1111111,1111111,1111111,1111111, 
1111111 , 1111111 , 1111111 , 1111111 , 
2111111.2111111,211111121111112111111.2111111,21111112111111, 
2111111,2111111,21111112111111 I; 
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/* Names of workers in each transputer. */ 
static int nj»'[total_n_pr] = { 
0,1,23,4,5.6.7.8,9,10,11, 
0.1,23,4,5,6.7.8.9.10.11, 
0,1,23,4,5,6,7,8.9,10,11, 
0,1,23,4,5.6,7,8,9,10,11, 
0,1,2,3,4,5,6,7,8,9,10,11, 
0,1,23,4,5.6,7,8,9,10.11, 
0,1,2,3,4,5,6,7,8,9,10,11, 
0,1,2,3,4,5,6,7,8,9,10,11, 
0,1,2,3,4,5,6,7,8,9,10,11, 
0,1,2,3,4,5,6,7,8,9,10,11, 
0,1,2,3,4,5,6,7.8,9,10,11, 
0.1,23,4.5,6,7.8,9,10,11, 
0,1,23,4,5,6.7,8,9.10.11, 
0,1,2,3,4,5,6,73.9,10.11, 
0.1,23,4,5,6,7,8,9,10,11 ): 


s_comm 1 jouterjnit(total_prs.trs,unders,prs,100); 

/* User enters the lower left comer coordinates of the whole map here. */ 
cout «“ENTER X COORDINATE FOR ORIGIN: *• «'\n’; 
cin »org_x: 

cout «"ENTER Y COORDINATE FOR ORIGIN: “ «‘\n'; 
cin >x>rg_y: 


for (tr_s=0; tr_5i<5: lr_s++)| 
for (tr_y5=0: tr_y<3: tr_y++){ 
for (3i_counten=0; x_counter<4: x_counter++)( 
for (y_countei^=0; y_counter<3: y_counter++){ 
orgl_x*org_x+(tr_x*4*256)+x_counter*256; 

Orel v=org v-fftr v*3*256)+v counter*256: 

map_c mapl(orgl_x, orgl _y, MAP_SIZE31AP_SIZE,GRID_S1ZE); 
map c_map; 

map_s_com map_s_com: 

/* Sends map */ 

c_map = mapl.map_c_to_map0; 
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/* Conversion of mn)_c class to class before sending is done*/ 
if (addr < toCal_n_pr) | 

m£q(_s_com.nia(i_send(n_tr[addr]. njwladdr], c_in^, s_comml); 

) 

addr++; /• Determines the worker address for map portion to be sent. */ 

1 

I 

cout«“12 blocks of elevsttion data sent to transputer “ 

«addr/12«‘Nn’; 

} 

) 

cout«“Each 15 transputer is loaded with 12 blocks of elevation data “«‘\n’; 
CMD_INFO cmdjnfo; 

cout«“The server is ready to receive the start and goal point information!” 

f* The communication link is established between two Sun stations here and the 
information of two points in the area for LOS calculation is received. */ 

/* Opens socket on server •/ 
if (open_stream_s(SERVER_PORT_NUMBER) < 0) 
cout «“Error open Vi”; 

if (teceiw_buf_s((char*)info,&size) < 0) cout« “Error in receiving'n": 

a=K!ouble(info[0]); 

b=double(info[l]): 

c=double(info[2]); 

x=double(info(3]); 

y=double(info[4]); 

z=double(info[5]); 

vect« start(a,b,c); 


vector goal(x,y.z); 
goal = goal -I- agent; 
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cmd_uifo.stait = start; 
cmd_info.goa] = goal; 

s_comml.bcast_d(si2eof(cmd_ijifo),(char*)&cmd_info,50); 
sum = s_comml.lislen(l(X)); 

f* The LOS result will be “0” if LOS exists, or will be “1 ” if LOS doesn’t exist and it will be sent 
to the server which represents Janus. */ 
if (sum!=0) 

los_result=float(sum/sum); 

else 

lcis_rcsult=float(sum); 

cout« “Sum is “ « dec « sum « “'n’« flush; 

cout« “LOS Result is “ « dec «los_result« ‘Nn’« flush; 

send_buf_s((chai*)&los_iesuIt,sizeof(flDat)); 

) 

s_comm 1 .tominatefSO); 
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FILENAMK.: dient_main.C 

AUTHOR.: Dr. Se-Hung KWAK & Cem Ali DUNDAR 

DATE.: October 1993 

DESCRIPTION.: This program runs in a servw other than the one in which the man program runs. 


The user is asked to enter the infonnation about the two points in the area 
between which LOS calculation will be made.This information is sent to the 
main server via the communication link established between them. Ideally the 
sender is considered to be Janus.After sending the point information, the result 
is expected from the main server. When the result is received, it is displayed on 
the screen.This procedure can be repeated as many as the user wants. 


#include <iosiream.h> 

#include “unix_comm.h'’ 

void main(int argc, char *argv[2]) 

1 

float a,b,c,x,y,z: 
float bufl6]; 
int size; 
float ‘sum; 

if (open_stream_c(argv[l],CLlENT_PORT_NUMBER) < 0) 
cout« “Error open W; 

for(;:)( 


coot« “Enter the x-coordinate of start point 

cin»a; 

bufl0]=a; 

cout« "Enter tte y-coordinate of start point 
cin »b: 
bufll]=b; 

cout« “Enter the height of start point 

cin »c; 

buf[2]=c; 

cout« “Enter the x-coordinate of goal point 
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buf[3]=x: 


cout« “Enter the y-coordinate of goal point :”«‘'Nn’ 
cin »y; 
buf[4]=y; 

cout« “Enter the height of start point 

cin »z; 

buf[S]=z; 

send_buf_c((char •)buf,sizeof(float)*6); 
cout«‘Two points sent to serveiNn”; 

receive_buf_c((char *)buf,&size); 
sum = (float *)buf; 


cout« “Result is« ‘sum « “ Vi”; 

cout« “ If you want to continue, type ‘y’ Nn”; 

cin » ch; 

if (ch = ‘n’) break; 

I 

close_stream_c(); 
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APPENDIX B - HOST COMPUTER (PC) SOURCE CODE 


This appendix contains the source listings of the C++ code developed for the host 
computer which is a PC that is used in this thesis. They are stored in files as listed below: 

1. line.h 

2. los_com.h 

3. map.h 

4. map_crx.h 

5. plane.h 

6. rout_cmd.h 

7. router.h 

8. router2.h 

9. routerS.h 

10. s_los.h 

11. tr_comm.h 

12. vector.h 

13. linc.cpp 

14. map.cpp 

15. map_crx.cpp 

16. plane.cpp 

17. router.cpp 

18. routert.cpp 

19. routei2.cpp 

20. router3.cpp 

21. sjos.cpp 

22. tr_comm.cpp 

23. tr_commtcpp 

24. vector.cpp 
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25. worker.cpp 

26. worker.lnk 

27. btestlSO.cfg 
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HLENAME. 

AUTHOR. 

DATE. 

DESCRIPTION... 


Dr. Se-Hung KWAK & Cran AM DUNDAR 
September 1993 

Header file for description of line equation class and it; 


#ifndefLlNE_H 

#defineLINE_H 


#include “vector.h” 


class line { /• t = Pt+p:^o *1 

vector start: 
vector direction; 
public; 
lineOll: 

Une(vector ptl, vector dir); 

vector get_startO {return start;); 
vector get_directionO (return direction;); 

): 

#endifLINE_H 
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FILENAME. 

AUTHOR. 

DATE. 

DESCRIPTION. 


los_com.h 

Dr. Se-Hung KWAK & Cem Ali DUNDAR 
.; September 1993 

.: Header file for two structs. One of them is for information about map and the 
other is for information about two points in the area. 


#ifndefLOS_COM_H 
#define LOS_COM_H 


#include “vector.h” 


I* Contains the lower left comer coordinates, the size and the grid size of map portion which is sent to 
transputers at a time. */ 
struct MAP_INFO{ 
int stait_x. start_y, size_z, size_y; 
double grid_size: 

1 : 


I* Contains two vectors which have the information of two points between which LOS calculation is 
made. */ 

struct CMD_INFO( 
vector start, goal; 








FILENAME.; map.h 

AUTHOR.; Dr. Se-Hung KWAK & Cem Ali DUNDAR 

DATE.: September 1993 

DESCRIPTION.: Header file for the declarations of the map class and the map class functions. 


#ifndefMAP_H 
#defme MAP_H 
#include “vector.h" 
class map { 
public: 

struct map_rep{ 

int start_x, start_y. size_x, size_y; 

double grid_size: 


int refs: 

map_repO {refs = 1;) 


mapO: /• Constructors •/ 

mapfint start_x jnt stait_y,int $ize_x4nt size_y Rouble grid.sizeont* data); 

mapfconst map& map); /* Copy constructor *! 

map& operators(const map& map); /* Assignment operator*/ 

~map(); 

/* Gets the lower left comer coordinates, the size and the grid size inftnmation of map. */ 

int get_stan_xO I return p->start_x;); 

int get_start_y() (return p->start_y;); 

int get_si2e_x() (return p->size_x;); 

int get_size_y() (return p->size_y;l; 

double get_grid_size() (return p->grid_size;(; 

int* get_dataO (return p->data;l: 

vector to_m^_coord( vector loc); 
int higher_than(vector& loc): 
int te!Tain_height(int& grid_x, int& grid_y); 
int map_|iost(int grid_x, int grid_y): 

1; 


#endifMAP_H 
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FILENAME.: map_crx.h 

AUTHOR.: Dr. Se-Hung KWAK & Cem Ali DUNDAR 

DATE September 1993 

DESCRIPTION.: Header file for the source code which checks whether LOS passes through a map 

contained in a transputer. 


#ifndef MAP_CRX_H 
#denneMAP_CRX_H 

#include “plane, h” 

#include "map-h” 

class map_crx ( 

double map_x_min, mtg)_y_min, map_s_max, map_y_max; 
public: 

map_crx() )}: 
map_cr!t(map m^l); 

void set_value(m!^ mapl): 
int inside_p(vector pt); 

int mtgj_crossing(vector pi, vector p2, vector& start, vector* end); 
int map_intersect(vector p 1, vector p2, vector* start, vector* end); 
); 

#endifMAP_CRX_H 
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FILENAME.: plane.h 

AUTHOR.: Dr. Sc-Hung KWAK & Cem Ali DUNDAR 

DATE.: September 1993 

DESCRIPTION.: Header file for description of plane class and its functions. 


#ifndefPLANE_H 
#defme PLANE.H 

#include “vectw.h” 
#include “line.h” 


class plane { 

vector unit.normal; /*unit normal vector ♦/ 
double distance; /* -distance from origin •/ 

planeQ (); 

plane(vector normal, double dist) { 
unit.normal = normal.normali 2 e(); 
distance ^ dist; 

) 

/* If line is parallel to a plane, then lelOO is returned */ 

/* If line is parallel to a plane and on the plane, this routine also return lelOO. */ 

/* If start of a line touches a plane without being parallel to the plane, then it will return zero distance */ 

double plane_distancc(vector velocity, vector position); 

int plane_intersection(line line, vecta'& pt, double& distance); 

int plane_line_cross(line linel, vector* pt, double* distance); 

1 ; 

#endif 
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FILENAME.: rout_cmd.h 

AirniOR.: Dr. Se-Hung KWAK & Cem AM DUNDAR 

DATE.: September 1993 

DESCRIPTION.: Header file which contains the routing information for i 


#ifndef ROLrr_CMD_H 
#define ROUT_CMD_H 


! of all routing source 

'••******♦******•/ 


#defineROUTER_BUF_SIZE 1024 


/• Networic definition (actually tree) 
master 

routejO --writers 
router lrouter2 

routerll routerl2 router21 nxiter22 router23 


one node can have up to three descendant nodes, 
one node can have many workers. 

•/ 

/* 

ID number for routerl2 is 1001 
ID number for routerl23 is 111001 
•I 

/• 

Task number 

start ftomO!!!! (cf,routeis,0,1.2,11,12.13,21,22..) 

For example, first task connected router 12 is taskl20 and 
NTS field in send_map is 0. 

*1 


/* 

Port Numbers 

1^3 ; loww (may none connected) 
4.. :tasks 
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I* init iTCSsage format (cmd=0 «1) */ 

/• 0 cmd #_of_tasks #_of_k>wer_router destination cunentjevel*/ 
/•I 3 4 4 16 4bits*/ 

/•O CMD NTS LOW DST CLL */ 

/• send_map message format {cmd=2) */ 

/• 0 cmd task# ?77 destination 777*/ 

/• 1 2 4 4 16 4 bits*/ 

/•O CMD NTS 777 DST 777 */ 

/* map-size*/ 

/* 32 */ 

/• map data •/ 

/• variable length */ 

/• bcast_req message format (cmd=3) */ 

/• 0 cmd size ???*/ 

/•I 3 8 20bits*/ 

/•O CMD BCS 777 •/ 

/• BCS size message follows */ 

/* temiinate message foimat (cmd=4) */ 

/• 0 cmd 777??? */ 

/•I 3 28bits*/ 

/•O CMD 77? •/ 

/• cmd 0: init (start) 

1 ; terminate init 
2: send map 

3 ; beast reqest (los requests automatically repli^ by workers) 

4: terminate 


#define START_1NIT 0 
tdefine TERMINATE_INrr 1 
#defmeSEND_MAP2 
fdefine BCAST_REQ 3 
#defme TERMINATE 4 

fdefine ROUTE_CMD_MASK 0x70000000 
fdefine ROinE_hrre_MASK OxOFOOOOOO 
fdefine ROUTE_LOW_MASK OxOOFOOOOO 
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#defmeROUTE_DST_MASK OnOOOFFFFO 
#defme ROUTE_CLL_MASK OxOOOOOOOF 
#defmeROUTE_BCS_MASK 0 j[0FR30000 


#defme ROUTE_CMD_SHIFT 0x10000000 
#defme ROUTE_NTS_SHIFT 0x01000000 
idefme ROUTE_LOW_SHIFr 0x00100000 
#define ROUTE_DST_SHIFT 0x00000010 
#defme ROUTE_CLL_SHIFr 0x00000001 
#define ROUTE_BCS_SHIFT 0x00100000 

!* Use divides and multiplies instead of shifts for qieed */ 

#defme ROUI1E_UNPACK_CMD(n) ((n & ROUTE_CMD_MASK) / ROUTE_CMD_SHIFD 
#define ROUTE_UNPACK_NTS(n) ((n & ROUTE_NTS_MASK) / ROUTE_NTS_SHIFD 
#define ROUTE_UNPACK_LOW(n) ((n & ROUTE_LOW_MASK) / ROUTE_LOW_SHIFD 
tdefine ROUTB_UNPACK_DST(n) ((n & ROUTE_DST_MASK) / ROUTE_DST_SHIFD 
#denne ROUTE_UNPACK_CLL(n) ((n & ROUTE_CLL_MASK) / ROUTE_CLL_SHIFr) 
#defme ROUTE_UNPACK_BCS(n) ((n & ROUTE_BCS_MASK) / ROUTE_BCS_SHIFD 


Sdefine ROUTE_PACK_CMD(p.n) p=(p & (~ROUTE_CMD_MASK)) I (n*ROUTE_CMr)_SHIFr) 
♦define ROUTE_PACK_NTS(p.n) p={p & (-ROUTE_NTS_MASK)) I (n*ROUTE_NTS_SHIFD 
♦define ROUTE_PACK_LOW(p,n) p=(p & (-ROUTE_LOW_MASK)) I (n*ROUTE_LOW_SHIFT) 
♦define ROUTE_PACK_DST(p,n) p=(p & (-ROUTE_DST_MASK)) I (n*ROUTE_DST_SHIFT) 
♦define ROUTE_PACK_CLL(p,n) p=(p & (~ROUTE_CLL_MASK)) I (n*ROUTE_aX_SHIFr) 
♦define ROUTE_PACK_BCS(p.n) p=(p & (~ROUTE_BCS_MASK)) I (n*ROUTE_BCS_SHlFT) 

♦en(lifROUT_CMD_H 
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FILENAME 
AUTHOR 
DATE.... 
DESCRIPTION. 


Dr. Se-Hung KWAK & Cem Ali DUNDAR 
September 1993 

Header file for the source code which performs the touting for the current 
topology (rf transputer netwoik. 


#ifndefROUTER_H 

#defineROUTER_H 


#include <chan.h> 
#include “rout_cmd.h" 

I* 

Port Numbers 


0: upper 

1.23 : lower (may none connected) 

4..; tasks 

•/ 

#defme UPPER_PORT 0 

#define FIRST_LOWER_PORT_NUMBER 1 

#denne FIRST_TASK_PORT_NUMBER 4 

class router { 
int router_id; 
int level; 

int has_leaf_node_p; 
int last_lower_port_number, 
int last_task.jx)rt_number; 

CHAN **in_ports: 

CHAN **out_ports; 


char router_buf[ROUTER_BUF_SIZE]: 
public; 

routerfCHAN *in_poitsn,int ins, CHAN *out_poitsn4nt outs); 
void init(void); 
int crad_type(void); 
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void send_map(void); 
void bcast_req(void); 
void teiminate(void); 
void answei(void); 

void trans_map(int port_numberdm map_size); 


#endifROUTER_H 
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FILENAME.: router2.h 

AUTHOR.; Dr. Se-Hung KWAK & Cem Ali DUNDAR 

DATE.; September 1993 

DESCRIPnON.; Header file for the source code which performs routing between transputers. 


#ifndefROUTER2_H 
#defiiie ROUTER2_H 

#include <chan.h> 
Mnclude “tout_cmd.h” 


class router2 1 
CHAN **in_ports; 
iixins; 

CHAN ♦*out_ports; 


public; 
routet20(); 

router2(CHAN *in_potts[] jnt ins. CHAN *out_pons[] 4 nt outs); 

void touter_init(int dts, ini low, int nts); 

void router_init_done(void); 

void sead(int dst, int nts, int size, char* buf); 

void bcast(inl size, char* buf); 

int lisien(void); 

void teiiniiiate(void); 


#endifROUTER2_H 
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FILENAME.: roiiterS.h 

AUTHOR.: Dr. Se-Hung KWAK & Cem Ali DUNDAR 

DATE.: September 1993 

DESCRIPTION.: Header file for the source code which perfwms routing in a transputer. 


#ifndefROUTER3_H 

#defmeROUTER3_H 

#include <chan.h> 
tinclude “rout_cmd.h” 

#defuie SEND SEND_MAP 
idefine BCAST BCAST_REQ 
/•TERMINATE comes from “rout_cmd.h'’ */ 

class rouier3 | 

CHAN **in_ports; 
int ins; 

CHAN **out_ports; 
int outs; 
int message; 
int retum_va]ue; 

public: 

router3(CHAN *in_portsl[],int insl, CHAN ‘out_p(atsl []4nt outsl); 
int cmd_type(int& size); /* return type as well as size of data */ 
void receive(int size, char* buf): 
void answer(int value); 
void terminate!void): 

): 


#endifROUTER3_H 
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FMNAME.:s_los.h 


AtJTHOR.: Dr. Se-Hung KWAK & Cem Ali DUNDAR 

DATE.: September 1993 

DESCRIPTION.: Header file for the source code which perfwms LOS calculations between two 



#ifndefS_LOS_H 
#defme S_LOS_H 


tinclude “vector.h” 
#include “m^.h” 


sJosOO 

/• Performs LOS calculations. */ 
int (lo_s_los(vector start, vector goal, map& mapl); 
}: 


#endifS_LOSJH 
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FEiNAME. 

AUTHOR. 

DATE. 

DESCRIPTION. 


tr_comm.h 

Dr. Se-Hung KWAK & Cem All DUNDAR 
September 1993 

Header file for the source aide which performs the communication between 
SUN station and transputeis. 


#ifndefTR_COMM_H 

#denneTR_COMM_H 


#include <chan.h> 
#include "routei2.h” 


const int ROUTER_INn'_S = 1; 
constintSEND_S = 2; 
constintBCAST_S = 3: 
constintLISTEN_S»4: 
const int TERMINATE_S = S; 

class tr_comm { 
touter2 router2a: 


CHAN ••out_ports; 


public; 

tr_comm(CHAN *in_ports[], int ins, CHAN *out_potts[], int outs); 

int cmd_typeO: /* Return type */ 

void router_init(void): 
void send(void); 
void bcast(void); 
void listen(void); 
void terminate(void): 


#endifTR_COMM_H 
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FILENAME.: vector.h 

AUTHOR.: Dr. Se-Hung KWAK & Cem Ali DUNDAR 

DATE.: September 1993 

DESCRIPTION.: Header file for the description of the vector class and vector class (^rations. 


#ifndefVECTOR_H 
#define VECTOR_H 

class vector { 
double x,y,z; 

vector(); 

vector(double xl, double yl, double zl); 

double get_x() (return x:}; 
double get_y() (return y;); 
double get_zO (return z:); 

friend int operator=( vector vl, vector v2); 
friend vector operator+(vector vl, vector v2): 
friend vector operator-(vector vl, vector v2): 
friend vector operator*(double a. vector vl); 
double dotptod(vector vl); 
double magnitude(void); 
vector normalize(void); 

): 

#endif vector_H 
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FILENAME.: line.cpp 

AUTHOR.: Dr. Se-Hung KWAK & Cewi Ali DUNDAR 

DATE.: Seplembw 1993 

DESCRIPTION.: This source code is for a line equation. 


finclude “line.h” 

line;:Une(vector pll, vector dir) 
I start = ptl; direction = dir;) 
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FE-ENAME.; m^j.cpp 

AUTHOR.: Dr. Se-Hung KWAK & Cem AM DUNDAR 

DATE.: September 1993 

DESCRIPTION.: This source t»de deflnes the map class functions. 


finclude “map.h” 

map::map() /* ConstructCM-*/ 

( 

p = new map_rep; 

p->start_x = 0; p->start_y = 0; p->size_x = 0; p->size_y = 0; 
p->grid_size = 0.0; 
p->data = 0; // null pointer 

) 

map:;map(int start_x 4 nt start_y,int size_x4nt size_y.double gri[d_size 4 nt* data) /* Constructor •/ 

{ 

p = new map_rep: 

p->start_x = start_x; p->start_y = start_y; 
p->size_x = size_x; p->size_y = size_y; 
p->grid_size = grid_size; 
p->data = data; 

I 

map::niap(const map& map) /* Copy constructor */ 

{ 

map.p->refs++; 
p = map.p; 

I 

map& map::operator=:(const map& map) J* Assignment operator */ 

( 

map.p->refs++; 
if (-p->refi5 = 0) { 
deleteO p->data; 
delete p; 

1 

p = map.p; 
return *0115; 

) 
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map::-map() /• Destructor */ 

{ 

if (-(p->refs) = 0) ( 
delete[] p->data: 
delete p; 


vector map"to_map_coord(vector loc) 

) 

vector map_offset(((double)p->start_x)*p->grid_size, 
((double)p->start_y)*p->grid_size,0): 

vector loc_wn_map = loc - inap_offset; 
return (loc_wrt_m^): 

) 

int m^::higher_than(vector& loc) 

( 

int grid_x = (int) ((loc.get_x0 - p->stan_x*p->grid_size)/))->gtid_size); 
int grid_y »(int) ((loc.get_y() - p->start_y*p->grid_size)/p->grid_size); 
retuTn(p->data[gTid_y*p->size_x+grid_xl > loc.get_zO): 

1 

int map::terrain_height(int& grid_x, int& grid_y) 

( 

return tnapj»ost(grid_x,grid_y): 

) 

int map::tnap jx)st(int grid_x, int grid_y) 

{ 

index = p->size_x*gtid_y + grid_x; 
return p->data[index]; 
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FILENAME map cnc.c|q> 

AUTHOR Dr Se-Hung KWAK & Cem Ali DUNDAR 

DATE. S pt mber 1993 

DESCRIPTION.: This source file checks whether LOS passes through a map contained 

iranspuier or noL 


#include “map_crx.h” 

map_cnt::map_cr!t(map mapl) 

( 

map_)i_mm = double(mapl.get_staft_xO) * mapl.get_grid_sizeO: 
tn^_y_m>n = double(truq)Lget_stait_yO) * mapl.get_grid_sizeO; 

m^_s_max = map_x_min + double(mapl.get_size_x()) • mapl.get_grid_size(); 
map_y_max = map_y_min + double(mapl.get_size_y()) • mapl.get_grid_siie(): 


void mt^)_cr!t::set_value(map mapl) 

( 

map_x_min = double(mapl.get_start_xO) * mapl.get_grid_sizeO; 
tnap_y_min = double(mapl.get_stait_yO) * mapl.get_grid_sLzeO: 
map_x_max = map_x_min + double(mapl.get_size_xO) * mapLget_grid_sizeO; 
maP-y-max = map_y_min + double(mapl.get_size_yO) • mapl.get_grid_size(): 

} 

int m^_cni::insidej){vectw pt) 

I* inside_p includes boundary too. */ 
double delta = 0.00005; 

if ((pt.get_x0 > map_x_min-<lelta) && (pLget_x0 < map_x_max+delta) && 
(pLget_y() > m^_y_min-della) (pLget_yO < map_y_max+della)) 
retum(l); 
else 

retum(O); 
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int map_cra::m^_crossmg(veclorpl, vector p2, 
vector* start, vector* end) 

( 

if ((mside_p(pl))**(inside_p{p2))) { 
start = pi; 
end = p2: 
return 1;) 
else ( 

if (inside_|)(pl)) ( 
map_intersect(p 1 ,p2,px 1 ,px2): 
start = pi; 

return 1;) 

else if (mside_p(p2)) ( 
start« p2; 

map_intersect(p 1 ,p2,px 1 ,px2); 

return 1;) 
else { 

if (map_intersect(pl,p2,pxl,px2)) { 
start = pxl; 
end •> px2: 
return 1;) 
else 

return 0; 

) 

) 

) 


int map_crx::inap_intersect(vector pi, vector p2, vector* pxl, vector* px2) 

( 

/* This routine returns two intersection pts: pxl, px2 */ 
t* If they are identical, then pxl = px2 •/ 

/* If3Dpts,pl & p2, are given, then pxl and px2 are 3D pts •/ 

vector pt, pts[2]: 
double dist; 
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vector x_normal( 1,0,0), y_nonnal(0,l,0); 

plane plaiie_xl(x_nonnal, -1.0*m^_x_inin); 
plane plane_x2(x_normal, -1.0*map_x_niax): 
plane plane_yl(y_nonnal, -1.0*map_y_min); 
plane plane_y2(y_noitnal, -1.0*niap_y_tnax); 
vector delta = p2-pi; 
line linel(pl,p2-pl); 

int num = 0; 

/• Thrae are two distinct pts */ 
if (plane_xl,plane_line_aDSs(linel, pt, dist)) 
if (inside_p(pt)) { 
pts[num] = pt; 

if (plane_x2,plane_line_cross(linel, pt, dist)) 
if ((tnside_p(pt) && num && !(pts[num-l]=pt)) II inside_p(pt)) { 
pts[num]» pt; 
num++;) 

if (plane_y l.planeJine_cross(linel, pt, dist)) { 
if ((inside_p(pt) && num && !(p($[num-l]»>pt)) II inside_p(pt)) { 
pts[num] = pt: 
num++:) 

1 

if (plane_y2.planeJine_ctoss(linel, pi, dist)) 
if ((inside_p(pt) && num && !(pis[num-l]=pt)) II inskle_p(pt)) { 
pts[num] X pt; 

if (num = 0) 
return 0; 

elseif (num=l)| 
pxl = pts[0]: 
px2 = pts[0]; 
return 1;) 
elsej 

pxl = ]^[0]; 
px2 = pts[l]: 


} 
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FMNAME.: plane.q)p 

AUTHOR.: Dr, Se-Hung KWAK & Cem Ali DUNDAR 

DATE.September 1993 

DESCRIPTION.: This source code is fa-plane equations and functions. 


#include “plane.h" 

#include “vector.h" 

#mclude <maih.h> 

double plane::p]ane_distance (vector velocity, vector position) 

( 

/• plane (X-Q)N=0. Une X=P+tA. 
t = (Q-P)N/(AN), if A is normalized then t is signed distance. 

If t is infinitive, then plane-distance returns NUIX. 

otherwise, plane-distance returns distance. •/ 

vector A * velocity.normalizeO; 

vector N = unit_noimal; 

double dis = -1.0 * distance; 

vector Q = dis * N; 

vector Q_P = Q - position; 

double AN = A.doq)rod(N); 

double numerator = CLP.doq3rod(N); 

if(fabs(AN)<lE-100) 

retum(lElOO); 

else 

retum(numerator/AN); 

) 

int plane: :plane_intersection(line linel, vector& pt, double& distance) 

1 

vector velocity = linel.get_direction().notmalize(); 
distance = (*this).plane_distance( velocity, linel .gel_startO): 
if (distance < lElOO) ( 
pt = linel.get_start() + distance * velocity: 

return 0; 

I 
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ini plane::plane_line_cross(line linel, vecior& pt, double* distance) 

1 

vector velocity = linel.get_direction0.noimalizeO; 
distance = (*this).plane_distaiKe( velocity, linel .get_startO): 
if ((distance >= 0) && (distance < linel .get_direction0.magnitude())) ( 
pt = linel .get_stan() + distance • velocity: 
return 1;} 
else 

return 0; 
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FILENAME.: rouler.cpp 

AUTHOR.: Dr. Se-Hung KWAK & Cem Ali DUNDAR 

DATE.; September 1993 

DESCRimON.: This is the main routing source code. It handles routing for the current topology 

of transputer network. 


#include “router.h” 

#include <alt.h> 

#include <chan.h> 

router;:router(CHAN •in_portsin,int insl, CHAN *out_portsl[]4nt outsl) 

{ 

in_ports= injxrrtsl; 
ins = insl; 

out_ports = outjxrrtsl; 
outs s outsl; 

} 

int next_address(int destination, int currentjevel) 

{ 

tetum((de$tination »(curtEnt_level * 2)) & 0x00000003); 


void routen;init(void) 

( 

/* message format •/ 

/* 0 cmd #_of_tasks #_of_lower_router destination currentjevel*/ 
/* 1344 164bits*/ 

/* 0 CMD NTS LOWDSTCLL */ 

/* cmd 1; init (start) 

2: terminate init 
*/ 

for{;;)( 
int message; 

chanJn_word(&message.in_pons[0]); 


/* Checks whether to terminate init routine. 
This is detected by the first node. */ 
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if (ROLrrE_UNPACK_CMD(message) = TERMINATE_INIT) { 
for (im i=FIRST_LOWER_PORT_NUMBER; i<=last_lower_poit_number; i++) 
chan_out_word(message,out_poits[i]); 
break: 

) /* If there is no lower routers, then it automatically does not 
send anything. */ 

int destination = ROUTE_UNPACK_DST(message); 
int cuirentjevel = ROUTE_UNPACK_CLL(message): 
int next_chan = next_address(destination, currentjevel); 

if (!next_chan) ( /• This is the destination. */ 

routerjd = destination; /* Destination is ID. */ 
level = currentjevel; 

int num_ofJower_routers = ROUTE_UNPACK_LOW(message); 
lastJower_port_number = num_ofjower_routers + FIRST_LOWER_PORT_NUMBER-l; 
/• 0,1.. num_ofJower_routers, task_poits.... •/ 
int num_of_tasks = ROUTEJJNPACKJ4TS(message): 
last_task_pott_number= num_of_tasks + FIRST_TASK_PORT_NUMBER-l; 
if (num_ofjower_routers !=0) 
has_leaf_node_p = 1; 

hasJeaf_node_p = 0; 

} 

else ( 

message++: /* Increments cunentjevel counter. */ 

chan_out_word(message, out_poits[next_chan]); 

) 

I 


int routen:cmd_type(void) 

( 

chanJn_word(&message,in_ports[0]); 

retum(ROUTE_UNPAClC_CMD(message)); 

) 

void router.;lrans_map(int pOTt_number, int map_size) 

I 

chan_out_word(message,out_ports[port_number]): /• Sends header first. •/ 

int num_of_packets = inap_size / ROUTER_BUF_SIZE + 1; 
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int last_f>acket_size = m^_size % ROl]TER_BUF_SI2S: 
chan_out_wcwxi(map_size,out4)orts[port_nuniber]): I* Sends map size. */ 
while (num_of j>ackets>0) { 
if (num_of_packeis=l) 
if (last_packet_size > 0) | 

chan_in_message(last_packet_size.router_buf,in_ports[0]); 
chan_out_message(last_packet_size.iaiier_buf,out_ports[p(*t_number]);} 
else {/* nothing to transfer •/! 
else { 

chan_in_message(ROUTER_BUF_SlZE4txiter_buf4n_pons[0]): 

chan_out_message(ROUTER_BUF_SIZE,router_buf.ouI_ports[port_number]); 

1 


) 

void router:send_map(void) 


chan_in_word(&map_size4nj)orts[0]); 

int destination = ROUTE_UNPACK_DST(message); 

/* Two cases; This node’s task or pass down */ 
int next_chan » nezt_address(destination, level); 

if (!ne]it_chan) { /* This is the destination. */ 

!* Gets task number. •/ 

int task_port_number = ROUTE_UNPACK_NTS(message)+FIRST_TASK_PORT_NUMBER: 
trans_map(task_port_number4nap_size); ) 
else 

ttms_map(neat_chan4nap_size); 

) 

void router:;bcast_req(void) 

( 

int size = ROUTE_UNPACK_BCS(message); 
chan_in_message(size4Duter_buf.in_p<wts[0]): 

for (int i=FIRST_LOWER_PORT_NUMBER; i<=last_lowerjpott_number: i++) ( 
chan_out_word(message,out_potts[i]): /• Sends down */ 
chan_out_message(size4iouter_buf,out_ports(i]); 

} 
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for {i=FIRST_TASK_PORT_NUMBER: i<=Iast_task_port_number, i-w-) { 
chan_out_word{message,oui_poitsB]); /* Sends down. */ 
chan_out_message(size4ouler_biif,out_poits(i]): 

} 

1 

void routen;answer(void) 

( 

int sum = 0; /* Should be zero, now just testing mode. •/ 

int lower_sum, task_sum=0; 
int chan; 

for (int i=FIRST_TASK_PORT_NUMBER; i<=last_task_poit_number.i++) { 
chan = alt_wait_vec(ins, in_ports); 
chan_in_word(&task_sum,in_potts[chan]); 


for (i=FIRSTJLOWER_PORT_NUMBER; i<=last_lowerj)ort_number, i++) { 
chan « alt_wait_vec(ins, in_poits); 
chan_in_word(&lower_suminj>otts[chan]): 
sum = sum + lower_sum; 

1 

chan_out_word(sum,out_ports(0]); 

1 

void router.:terminate(void) 

{ 

for (int i=FIRST_LOWER_PORT_NUjMBER; i<=last_lower_pott_number, i-H-) 
chan_out_word(message,out_pons[i]); 

for (i»=FIRST_TASK_PORT_NUMBER; i<=last_task_port_number, i++) 
chan_out_word(message,out_ports[i]): 

) 
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FILENAME.routeit-cpp 

AUTHOR.: Dr. Se-Hung KWAK & Cem Ali DUNDAR 

DATE.; September 1993 

DESCRIPTION.: This source code performs routing for transputers. 


#include <chan.h> 

#lnclude “router.h” 

void main(int argc, char *argv[], char ♦envpO, 

CHAN *in_portsD, int ins, CHAN ♦out_portsD, int outs) 

( 

int exit_flag = 0: 

router router 1 (in_pons,ins,out_ports,outs); 

router! .initO; 

while (!eMt_flag) 
switch (routerl.cmd_typeO) ( 
caseSEND.MAP: 
routcrl .send.mapO; 
break; 

case BCAST.REQ: 

routerl.bcast_reqO: 

rouierl.answer(); 

bresdt; 

case TERMINATE: 
router 1 .terminateO; 
exit_flag = 1; 
break; 
default: 

/•error*/ 

break; 

1 
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FILENAME router2.cpp 

AUTHOF Dr.Se-HungKWAK&CemAliDUNDAR 

DATE. September 1993 

DESCRIPTION.: This source code performs routing between transputers. 


#include “routet2.h” 

#include <iostream.h> 

const int OUT_PORT_NUM =2; 
const int IN_PORT_NUM = 2; 

router2:;router2(CHAN *in_portsl[]4nt insl, CHAN *out_portslQ.int outsl) 

( 

in_pals= in_portsl; 
ins = insl; 

out_potts = out_ports 1; 
outs = outsl; 

) 

int convett_to_dst(int destination) 

{ 

f* Destination address does not contain zero. */ 
intdst=0; 

int digit = destination % 10; 
destination = destination / 10; 
while (digit) ( 
dst = (dst« 2) I digit; 
digit = destination % 10; 
destination = destination /10; 


) 

void touter2:;router_init(int destination, int low, int nts) 


int c\l = 0; /* Current level number */ 
ROUTE_PACK_CMD(message,START_INIT); 
ROUTE_PACK_NTS(messagejits); 
ROUTE_PACK_LOW(message,low); 
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ROirre_PACK_DST(message,convert_U)_dst(destinati(Mi)); 

ROUTE_PACK_CLL(message,cB); 

chan_out_word(message,out_poits[OUT_PORT_NUM]); 


void routet2::router_init_done(void) 

{ 

int message = 0; 

ROirrE_PACK_CMD{message,TERMINATE_INrr); 

ROUTE_PACK_LOW(message,2): 

chan_out_word(message,out_pofts[OUT_PORT_NUM]); 

1 

void router2::terminate(void) 

{ 

int message = 0; 

ROUTE_PACK_CMD(message,TERMINATE); 
chan_out_word(message,out_ports[OUT_PORT_NUM]); 

1 

void router2::send(int destination, int nts, int size, char* buf) 

1 


ROUTE_PACK_CMD(message, SEND.MAP); 
ROUTE_PACK^NTS(message, nts); 

ROirre_PACK_DST(message, convert_to_dst{destination)); 

/* Sends “header” •/ 

chan_out_word(message,out_potts[OUT_PORT_NUM]); 

/♦Sends “size”*/ 

chan_out_word(size,outjports[OUT_PORT_NUM]); 
char* bp = buf; 

int num_of_packets = size / ROUTER_BUF_SIZE + 1; 
int last_packet_size = size % ROUTER_BUF_SIZE; 
while (num_of_packets>0) | 
if (num_of_packets=l) 
if (last_packet_size > 0) 1 

chan_out_message(last_packet_size,lq»,out_ports [OUT_PORT_NUM]);) 
else ( /* Nothing to send */ ) 
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else ( 

chan_out_message(ROUTER_BUF_SI2aE,bp,out_portstOUT_PORT_NUM]); 
bp += R0UTER_BUF_SIZE: 

1 

num_of_packBts-: 


I 

void router2;:bcast(int size, char* buO 

{ 


ROUTE_PACK_CMD(inessage,BCAST_REQ): 
ROUTE_PACK_BCS(messagejiize); 
chan_out -i'Trd(mcssage,out_jorts(OIJr_PORT_NUM]); 
chan_oui sage(size,buf,ourjiorts[OUT_PORT_NUM]); 

) 

int router2::}isten(void) 

( 

int message; 

chan_in_word(&message, injx)rts[IN_PORT_NUM]); 
return message; 

1 
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FILENAME.: routerS.cpp 

AUTHOR.: Dr. Se-Hung KWAK & Can Ali DUNDAR 

DATE.; Sepcemba 1993 

DESCRIPTION.: This source code performs routing for workers. 


#include “routerS.h” 


routa3::n)uter3(CHAN •in.jwitslDant insl, CHAN ♦out_poitslO,int outsl) 

{ 

in_parts= in_patsl; 
ins = insl; 

out_potts = out_portsl; 


int router3;:cmd_type(int& size) 

{ 

chan_in_word(&message.in_ports[0]): 

int cmd = ROUTE_UNPACK_CMD(inessage): 

if(cmd = SEND) 

chanjn_word(&size,injiotts[0]); 

else 

size = ROUTE_UNPAac_BCS(message); 
retuni(cmd): 

I 

void router3::receive(int size, char* buO 

( 

char* bp = buf; 

int num_of_packets = size / ROUTER_BUF_SIZE + 1; 
int last_packet_size = size % ROUTER_BUF_SIZE: 

while (num_of_packets>0) { 
if (num_of_packets=l) 
if (last_packet_size > 0) { 

chan_in_message(last_packet_size,1^4n_potts[0]); 1 
else { /* Nothing to send */) 
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else( 

chan_in_message(ROUTER_BIJF_SlZE,ljp,in_ports[0]): 
bp += R0UTER_BUF_S1ZE: 

1 

num_of_pa:fcets-; 

1 

} 

void router3::answei<int value) 

I 

chan_out_word(valueflutjpons[0]); 

void rouler3::terminate(void) |) 
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FILENAME.: s_1os.ch> 

AUTHOR.; Dr. Se-Hung KWAK & Cem AJi DUNDAR 

DATE.: September 1993 

DESCRIPTION.: This source code performs LOS calculations between two points in the map 

Returns 0 if LOS exists, returns 1 otherwise. 


#include <math.h> 

#include “s_los.h“ 

#include “map.h" 

int s_los::do_s_los(vector start, vector goal, map& mapl) 

{ 

vector del = goal-start; 
int del_xi, del_yi; 

del_xi = (int) (fabs(del.get_x())/ mapLget_giid_sizeO); 
del_yi»(int) (fabs(del.get_y())/ mapLget_grid_sizeO): 
steps »(del_xi > del_yi) ? del_xt: del_yi; 

/* Steps 1 is necessary, because without adding 1, the last goal point is not tested. */ 
vector deltSLStep = (1.0/steps)*del; 
vector checkjoc « start; 

for (i=0:i<steps;i-H-){ 
if (mapl.higher_than(checkJoc)) 
return 1; 

ch«:k_loc = checkjoc + delta_step: 









FILENAME.: tr_coniin.c[q) 

AUTHOR.: Dr. Se-Hung KWAK & Cem Ali DUNDAR 

DATE.: Sepcember 1993 

DESCRIPTION.: This source code handles the communic^on between transputers. 


tinclude “tr_comm.h” 

#include <chan.h> 

#include <iostream,h> 

#include “los_com.h” 

const int IN_PORT_NUM=4; 
const int OUT_PORT_NUM=4; 

tr_comm::tr_comm(CHAN •in_portsl[], int insl, CHAN *out_portsin, int outsl) 

( 

router2a = router2(in_portsl, insl, out_portsl, outsl); 
in_portS!« in_portsl; 
ins > insl; 

out_ports » outjtortsl; 
outs M outsl; 

) 

int tr_comm::cmd_type() 

{ 

int cmd; 

chan_in_word(&cmdjn_potts[IN_PORT_NUM]); 

retum(cmd): 

) 

void tr_comm::K)uter_init(void) 


chanJn_word(&num_trs4n_ports[IN_PORT_NUM]): 

trs = new int[num_trs]: 
undm = new int[num_trs); 
prs = new int[nuin_trs]; 

int size=num_trs*sizeof(int); 
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chan_in_message(si2e,(char*)trs,injpoits[IN_PORT_NUM]); 

chan_in_message(size,(char*)unders4n_ports[IN_PORT_NUM]): 

chanJn_message(size,(char*)prs4n_poits[IN_PORT_NUM]); 

for (int i=0; i<nuin_lis: i++) 
router2a.n)uta-_init(tre[i],unders[i],prs[i]): 


/• Terminates initialization. •/ 
router2a.router_init_done(); 

) 

void tr_comm::send(void) 

{ 

intdst; 

chan_in_word(&dst4n_p(»ts[IN_PORT_NUM]); 


chan_in_word(&nts4n_poits[IN_PORT_NUMl); 

int size; 
char* buf; 

chanJn_word(&size4n_ports[IN_PORT_NUM]); 
buf = new char[size]; 

chan_in_message(size,bufjnj)orts[IN_PORT_NUM]); 
n)uter2a.send(dst, nts, size, buf ); 

} 

void tr_comm::bcast(void) 

{ 


chan_in_word(&size4n_potts[IN_PCfftT_NUM]); 
char* buf; 

buf = new char[size]; 

chan_in_message(size.buf4n_ports[IN_PORT_NUM]); 
CMD_INFO ’crndjufop: 
cmd_infop = (CMD_INFO*)buf; 
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routBr2a.bcast(size, buf); 


void tr_comm;;Usten(void) 

int value == routn2a.listen0; 

chan_out_woid( value,out_pons[OUT_PORT_NUM]): 

) 

void tr_coram::ierminate(void) 

( 

routet2a.tenninate0; 

) 
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FEJENAME.: tr_commt.cpp 

AUTHOR.: Dr. Se-Hung KWAK & Cem Ali DUNDAR 

DATE.: September 1993 

DESCRIPTION.: This source code handles the communication between SUN and transputers. 


void main(int argc, char ‘argyn, char ‘enypO, 

CHAN *in_ports[], int ins, CHAN *out_portsO, int outs) 

( 

int exit_flag = 0; 

tr_comm tr_comm l(injx>rts,ins,out_ports,outs); 
while (!exit_flag) 
switch (tr_comml.cmd_typeO) I 
case ROUTER_INn'_S: 
lr_comm l.routerJnitO; 
break; 

case SEND_S: 
tr_comin l.sendQ: 


caseBCAST_S; 

tr_comml.bcastO: 

break; 

caseLISTEN_S; 

tr_comml.Iisten(); 

break; 

caseTERMlNATE_S: 
lr_comm 1 .terminMe(); 
exit_flag = 1; 

default: /* Error */ 
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FILENAME vectw.ci^ 

AUTHOR Dr. Se-Hung KWAK & Cem Ali DUNDAR 

DATE. September 1993 

DESCRIPTION.-.This source code defines the v«:tor class operations. 


finclude "vector.h” 

#include <math,h> 

vector::vectorO (x=0.0; y=0.0: z=0.0:l: 

vector::vector(double xl, double yl, doublezl) {x=xl: y=yl; z=zl;); 
int operatoi^(vector vl, vector v2) 
retum((vl.x=»:v2.x) && (vl,y»»v2.y) && (v1.z=v2ji)): 


vector operator+(vector vl, vector v2) 

I 

vector v(vl.x+v2.x, vl.y+v2.y, vl.z+v2.z); 


vector operat0r-(vector vl, vector v2) 

( 

vector v(vl.x-v2.x, vl.y-v2.y, vl.z-v2.z): 


vector operator*(double a, vector vl) 

I 

vector v(a*vl.x, a*vl.y, a*vl.z): 

I 

double vecton:dotprod( vector v2) /• Dot laoduct •/ 

retum(this->x*v2.x + this->y*v2.y + this->z*v2.z): 
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r::magnitude(void) 


rctum(s<irt((*this).doqwod(*this))); 


vector veclOT;:normalize(void) /* Vector normalization •/ 

I 

vector result; 

double mag = (•this).magnttudeO; 

if(mag<lE-100){ 
resukx = 0.0; 
resulLy = 0.0; 
resulLz s 0.0;} 
else! 

result = (1.0/inag) * (*this); 

I 

letum(resuU); 
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/*••****•*“ 

FILENAME. 

AUTHOR. 

DATE. 

DESCRIPTION. 


worker.cpp 

Dr. Se-Hung KWAK & Cem Ali DUNDAR 
September 1993 

.: This source code handles the communication between routers and workers, 
passes all information to workers and gets the result which they found. 


#include “routerS.h” 
#include “los_com.h” 
#include “sjos.h” 


#include “map_crx.h” 


int num_cnt(int num, int* buf, int buf_si2e) 

{ 

int cnt = 0; 

for (int i=0: i<buf_si2e; i++) 
if (bufli]=num) cnt++: 


void main(int argc, char ‘argvQ, char ‘enypn, 

CHAN ♦in_ports[], int ins, CHAN *out_p<»ts[], int outs) 

{ 

/* three cases; get_map 
get_req & return answer 
terminate 


int exit_flag = 0; 
int size = 0; 
int* buf; 
int buf_size; 

CMD_INFO cmdjnfo; 

MAP_INFO map_info; 
vector test_s, test_g; 

map c_map; 

routers router3a(in_ports4ns,out_ports,outs); 
map_crx map_crxer, 
sjos losl; 
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while (!e)ut_flag) 
switch (router3a.cmd_type(sia!c)) { 

case SEND: 

router3a.teceive(size,(char*)&m^_info); 
router3acmd_type(size); 
buf_size = size/4: 
buf = new int[buf_size]; 
router3areceive(size,(char*)buO; 
c_map = inap(map_info,stait_x, map_info.start_y, 
map_info.size_x, map_info.sixe_y, 
m^_info.grid_size, buf): 

case BCAST: 

router3ajeceive(size,(char* )&cnid_info); 
map_crxer.set_value(c_map); 

if (map_crxer.map_crossing(cmdJnfo.start, cmdjnfo.goal, test_s, test_g)) { 
c_result * losl.do_s_los(test_s, test_g, c_m^); 

) 

else 

c_result = 0; 

router3aanswer(c_result); 

break; 


case TERMINATE: 
router3atetminate(); 
exit_flag = 1; 

default: /• Error •/ 
bre^; 
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FE.ENAME.: worker.Ink 

AUTHOR.: Dr. Se-Hung KWAK & Cem Ali DUNDAR 

DATE.: SeptembCT 1993 

DESCRIPTION.: Does the necessary links for workers. 


worker.bin 

router3.bin 

map.bin 

iTiap_crx.bin 

sjos-bin 

plane.bin 

line.bin 

vector.bin 
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FE,ENAME.: btestlSO.cfg 

AUTHOR.; Dr. Se-Hung KWAK & Cem Ali DUNDAR 

DATE.: SeptembCT 1993 

DESCRIPTION .: This configuration file are fw 15 transputers, one Sun SPARC Station and one 

PC Host! There are one router and 12 worker tasks for each transputers. 


processor host 
processor sun type=pc 
processor root 
processor pi 
processor p2 
processor pi 1 
processor p21 
processor pi 11 
processor p211 
processor pllll 
processor p2111 
processor pi 1111 
processor p21111 
processor pi 111 11 
processor p211111 
processor pi 111 111 
processor p2111111 


wire? 

root[0] 

host[0] 

wire? 

ioot[l] 

pim 

wire? 

root[2] 

p2[2] 

wire? 

root[3] 

sun[0] 

wire? 

pl[2] 

pIUl] 

wire? 

p2[l] 

p21[2] 

wire? 

pll[2] 

pllUl] 

wire? 

p21[l] 

p211[2] 

wire? 

plll[2] 

pimm 

wire? 

p211[l] 

p2111[2] 

wire? 

piiiira 

pllllUl] 

wire? 

p2111[l] 

p21111[2] 

wire? 

plllll[2] 

plllllUl] 

wire? 

p21111[l] 

p211111[2] 

wire? 

pllllll[2] 

pllllllUl] 

wire? 

p211111[l] 

p2111111[2] 


! Tad; connected U) filter cannot use 0 channel of task therefore, master has to have S ins & outs 
! Also a channel to filter has to be lowest number. 


task afserver 
task filler 
taskmaster 


ins=l outssl 

in$=2 outs=2 data=lSk 

ins=5 aits=5 dataslSk file="ir_commt.b4" 
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taskrouterO 
ta^ louterl 
taskiouter2 
taskrouterll 
taskn)utei21 
task tou term 
taskn)utei211 
taskrouterll 11 
taskrouter2111 
taskrouterll 111 
task iouter21 111 
taskrouterllllll 
task iouta211 111 
taskrouterll 11111 
taskiDuter2111111 


ins=20 outs=20 data=2k file=''router.b4'' urgent 
ins=20 outs=20 data=2k flle=”router.b4" urgent 
ins=20 outs=20 data=2k flle="rouler.b4" urgent 
ins=20 outs=20 data=2k file=”iouter.b4” urgent 
ins=20 outss:20 data=2k AIe=''iouter.b4" urgent 
ins=20 outss20 data~2k file=''router.b4'' urgent 
inss20 outs>20 data=2k file=’'router.b4” urgent 
insa20 outs=20 datas2k file="router.b4" urgent 
inss20 outs=20 data=2k file="router.b4" urgent 
inss20 outs=20 data=2k file=:’'touter.b4'' urgent 
ins=20 outs=20 data=2k riIe=''router.b4' urgent 
ins=20 outs=20 datas:2k file="router.b4" urgent 
inss20 outs»20 data=2k file="router.M" urgent 
ins=20 outs=20 data=2k file=*iouter.b4'' urgent 
ins=20 ouls=20 daia=2k file="router.b4" urgent 


task wwkerOO 
ta^ wokeiOl 
task w«ket02 
task wwkerOS 
task wo'kerOt 
task wOTkerOS 
task wwker06 
task wOTkeiO? 
tadcwOTkerOS 
task w«ker09 
task wrakerOlOO 
task workerOlOl 


outs=l data=275k file="woiker.b4" 
outs=l datas275k file="woiker,b4" 
outs=l data=275kfile="worker.b4" 
outs=l data=275kfile="wotker.M" 
outssl dataB27Sk file="woiker.b4" 
out$=l datas27Sk file=”wOTker.b4" 
outs=l dat^27Sk AIe=''worka'.b4” 
outs=l dalaB275k file="w«Mker.M" 
outs=l data=275k file="woiker.b4" 
outs=l data=27Sk flle=”wMker.b4" 
outssl dal»:27Sk file="worker.b4" 
outs^l data=275k file="woikw.b4" 


task workerlO 
task wwkerll 
task worker 12 
task wotkerO 
task worker 14 
task wotkerlS 
task workerl6 
task woricerH 
task w«kerl8 
task workerl9 
task workerl 100 
task workerl 101 


out^l data=27Sk fUe*’ 
outs=l data?27Sk file=' 
outs=l data=27Sk file=’ 
outs=l data=275k rile=' 
outs=l data=275k ftle=‘ 
outs=l dat2ts275k {ile=* 
outs=l data=275k fUe^’ 
outs=l data^275k file=* 
outs>l datas275k file=’ 
outs=l data3:275k file=’ 
outs=l dala=275k file=’ 
outs^l data=27Sk rile>' 


'worker.b4“ 

’worker.M" 

'worker.b4” 

■worker.b4" 

’worker.M" 

'worker.b4“ 

’worker.M" 

’wotker.b4" 

’worker.M" 

’worker.M" 

’worker.M" 


taskworker20 
task woriter21 
taskworket22 
task warker23 
task w(iker24 
task worker2S 
task w(Mker26 
task worker27 


outs=l daia3275k rile=’ 
outs=l data=275k file=’ 
outs=l daias275k file=’ 
outs=l dala=27Sk file=' 
outs=l data=27Sk file=’' 
outs-l data=275k rile=’ 
outs=l data=275k file=" 
outs=l data=27Sk file=’ 


■wwker.M" 

’worker.M" 

’worker.M" 

’wwker.M" 

’workw.M" 

woikCT.M" 
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Illlllll liliifiiiiii lllllilillll iiiiiiiiiiiiiiii 


woilcer28 ins=l out^l daia=275k file="worker.M" 

W(xker29 ins=l outs=I data=27Sk file="wc»ker.b4" 

wOfker2100 ins«l outssl data=275k file=!"workCT.b4” 

wc*ker2101 iiis=l outs=I data=27Skfile=‘'w«ker.b4‘’ 

wOTkerllO iiis=l outs=l data=275k rile="woiker.b4'' 

workerl 11 ins=l outs^l data=27Sk file=”workeT.b4" 

wOTkern2 ins=l outs=l daia=:275k file=”woiker.b4" 

workerl 13 ins*l outs=l (lataz:275k file«>"woiker.b4" 

workerl 14 iiis= 1 outs=l data=275k file=”woiker.M” 

wMkerllS ins=l outs=l daia=275k file="woiker.b4" 

workerl 16 ins=l outs=l datap27Sk nie=''woiker.b4" 

workerl 17 ins=l outs=l datas275k file=”worker.b4" 

wcakerllg ins=l outs=l data;=275k file="wotk«.b4" 

workerl 19 ins=l outs=l data=27Sk file=”woricer.b4" 

workerl 1100 ins=l outs=l data=275k file="worker.b4" 

workerl 1101 ins=l outs^l data=27Sk file="worker.b4” 

workerl 110 ins=l outs=l data=275k file=“worker.b4" 

workerl 111 ins= 1 outs^l data=27Sk file=”worker.M” 

workerl 112 ins=l outs=l dala=27Sk file="wotker.b4” 

workerll 13 ins=l outs=l data;=275k file="worker.b4" 

workerl 114 ins= 1 outs=l claia=275k file=''worker.M' 

workerl 115 ins=l outs=l daia=275k file="worker.b4" 

workerl 116 ins=l outs= 1 (iata=27Sk iile^'*worker.M" 

workerl 117 ins=l outs=l data=r275k Hle="worker.M" 

workerl 118 ins=l outs=l data=275k file="worker.M" 

workerl 119 ins=l outs=l datas275k file-"worker.M" 

workerl 11100 ins>l outs^l daia=27Sk rile="worker.M" 

workerl 11101 ins=l outs=l data=275k rile="worker.M" 

workerl 1110 ins=l outs-1 dai^27Sk file="woiker.M" 

workerl 1111 ins=l ouCs=l data=275k file="worker.M" 

workerl 1112 ins=l outs=l data^275k rile="wotker.M" 

workerl 1113 ins*l outs=l data=275k file=”worker.M" 

workerl 1114 ins=l outs=l data=275k flle="wotker.M" 

workerl 1115 ins*l outs=l dala=275k file="worker.M" 

workerl 1116 ins=l outs=l daia=275k file«"worker.M" 

workerl 1117 ins=l outs=l data=275k file^'worker.M" 

woikerll 118 ins=l outs=l data=275k file="worker.M" 

workerl 1119 ins=l outs=l data=275k file="wc*ker.M" 

wakerll 11100 ins=l outs=l daia=275k file=”worker.M" 

wwkerl 111101 iiis=l outs=l daia=275k file="waker.M" 

workerl 11110 iii$=l outs=l data=275k nie="worker.M" 

workerl 11111 ins=l outs=l datas275k file="worker.M" 

workerl 11112 ins=l outs=l dala=275k file="worker.M" 

wrxkerl 11113 iiis=l outs=l data=:275k file="wwker.M" 

workerl 11114 ins=l outs=l daia=275k file="wotker.M" 

workerl 11115 iiis=l outs=l data=275k file="worii:er.M" 

wwkerl 11116 ins=l outs=l daia=275k file="w<Mker.M" 

workerl 11117 ins=l outs=l dala=275k file="worker.M" 
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III! Illlllilllll llllllllllll llllllllllll III! 


wnkerlllllS iiis=l outs=l daias27Skfile^VorkerM” 

workerl 11119 ins=l outs=l data=275k fite="woiker.M" 

warkerl 1111100 ins=l outs=l data=275k file="worker.b4” 

woikerl 1111101 ins=l outs=l datas275k file="woiker.M" 


workerl 111110 ins=l outs=l data=275k file=”worker.b4" 

woikerlllllll ins=l outs^l daias:275kfile="workex.b4" 

workerl 111112 ins=l outs=l daia=:27Sk file="worker.b4" 

workerl 111113 ins=l outs=l daia=275k file='woTker.b4" 

workerl 111114 ins=l outs=l daia=275k file=”workw.M" 

woikerllllllS ins-1 outs=l data=275kfile-'worker.M" 

workerllllll6 ins=l out$=l data=275kfile-'worker.M” 

workerl 111117 ins=l outs-1 data=275k file-"woiker.b4" 

woikerl 111118 ins=l outs=l <]ata=275k fjle="worker.b4" 

workerl 111119 ins=l outs=l daia=275k Hle-’woiker.M" 

workerl 11111100 ins=l outs-1 daia-275k file=”worker.b4" 

workerlllllllOl ins=l outs-1 data=275k file="woiker.b4" 

workerl 1111110 ins=l outs=l data=275k fite="woiker.b4” 

workerllllllll ins=l out$-l data-27Skfile-’woiker.M” 

workerlllllll2 ins=l outs-l daia=275k flle="work«.b4" 

wakerlllllllS ins-1 outs-1 dal3-27Sk file-” woikerM" 

wn-kerl 1111114 ins=l outs=l daQ-27Sk file="woikCT.b4" 

workerl 1111115 ins=l outs-1 data-27Sk file-'wcsker.M” 

wwkerl 1111116 ins-1 outs-1 dats-27Sk file="woiker.b4" 

wwkerlllllin ins-1 outs-1 daia=275k file="woiker.b4* 

workerl 111 1118 ins-1 outs-1 daia-275k fite-’woker.M” 

wakerl 1111119 ins-1 wits=l data=275k file="worker.b4" 

workerllllllllOO ins-1 outs-1 data=275k file="worker.b4" 

wwkerl 111111101 ins-1 outs-1 dala=27Sk fiie=”woiker.b4” 


worker210 ins-1 outs-1 data-27Sk file=”worker.b4” 

woiker211 ins-1 outs-1 dat^275k file»"worker.b4" 

worker212 ins-1 out$-l daia=27Sk file="worker.b4" 

woiker213 ins-1 outs-1 data=275k file="worker.b4“ 

worker214 ins-1 outs-1 daia-275k file-"woiker.M" 

woikei215 ins-1 outs-1 data=275k nie="worker.b4" 

worker216 ins-1 outs-1 data-27Sk file="woiker.b4" 

woiker217 ins-1 outs-1 data-275k file="worker.b4" 

worker218 ins-1 outs-1 data-27Sk file-"woiker.b4" 

worker219 ins-1 out$=l data-27Sk file-"worker.b4" 

worket21100 ins-1 outs-1 daia-275k file-”worker.M” 

wotker21101 ins-1 outs-1 data-275k file=”worker.b4" 

worker2110 ins-1 outs-1 data-275k file-"wotker.b4" 

woiker2111 ins-1 outs-1 data-275k file="worker.b4" 

w<Hker2112 ins-1 outs-1 data=275k file-’worker.M" 

worker2113 ins-1 outs-1 data-275k file=”worker.b4" 
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Ill llllllllllll llllllllllll llllllllllll llllllll 


worter2114 ins=l ouCs=l data=27Sk fite="wofker.b4" 

woricer2115 ins=l outset dat^27Sk file="woikCT.b4" 

wofker2116 iiis=l outs=l data=27Sk file="woika-.b4" 

worker2117 ins=l outs=l data;:27Sk fi!e="woiker.l)4" 

wwkertl 18 ins=l outs=l dm=27Sk file='worker,b4” 

worker2119 iiis=l outs=l data=275k file="woiker.l>4" 

w«ker211100 ins=l outs=l data=27Sk file="woiker,b4" 

w«ker211101 iiis=l outs=l daia=27Sk file="wcwka'.b4” 

w<*ker21110 ins=l outs=l data=27Sk file="w<Mker.b4" 

wa-ker21 111 ins=l oots^l datas275k file="worker.b4” 

worker21112 ins=l outs=l data=27Sk file="worker.l)4" 

WM-kertl 113 ins=l outs=l data=27Sk file="woiker.b4" 

worker21114 ins=l outs^l data=275k file=“WMker.M” 

warker21115 ins=l outs=l data=275k fiIe="worker.b4" 

WM-ker21116 ins=l outs=l data=275k file=“worker.b4" 

worker21117 iiis=l ouCs=l data=275k file="worker.b4” 

WQiker21118 ins=l outs=l daia=275k file=”workcr.b4” 

worker21119 ins=l outset data=275k file="worker.b4“ 

warker2111100 ins*l outs=l data=275k file="worker.l>4" 

workei2111101 ins=l outs=l data=275k file=”worker.b4" 

worker211110 ins=l outs=I <lat^275k file="worker.b4" 

woiker211111 ins»l outs^l datas275k file="worker.M" 

worker211112 ins=l outs=l daia=275k files-woiker.M" 

wofker211113 ins=l outs=l data=275k file="woiker.b4” 

worker211114 ins=l outs^l data=275k file=''worker.b4'' 

wofker211115 ins=l outs=l data=27Sk file="worker.b4" 

woikei211116 ins=l outs=l datas275k file=”worker.b4" 

wcKker211117 ins=l outs=l data=275k fi!e="worker.M" 

woi1cef211118 ins=l outs=l data=275k file="woiker.b4- 

wofker211119 ins=l outs=l data»275k file=”wotker.b4" 

woiker21111100 ins=l outs=l daia=275k file="worker.b4" 

woikef21111101 ins=l outs=l data=275k file«"worker.b4” 

w(xkei2111110 iiis=l outs=l data=275k fUe="woiker.b4" 

worker2111111 ins=l outs=l (lata=275k file="woiker.b4” 

worker2111112 ins=l outs=l data=275k file=''worker.l>4" 

woiket2111113 ins=l outs=l data=275k file="woiker.b4" 

woikei2111114 ins=l outs=l data=275k file="woiker.l>4” 

woricei2111115 ins=l outs=l data=275k file="worker.M" 

wwkertl 11116 ins=l outs=l daia:°275k file=”worker.b4" 

wffl-ker2111117 irB=l out$=l (lata=275k file="woiker.b4" 

w«ker2111118 ins=l out»°l dala=275k file="woiker.b4” 

wcrker2111119 ins=l outs=l datas275k rile="worker.l)4" 

woiker211111100 ins=l outs=l data=275k file="woiker.b4" 

worker211111101 ins=l outs=l data=:27Sk file="worker.b4" 

wn-kei^l 111110 ins=l outs=l data=275k nie=''woiker.b4’ 

wwker21111111 ins=l outs=l data=275k file="worker.b4" 

wOTker21111112 ins=l outs=l daj»=:275k file="w«ker.b4" 
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outs=l data»275kfile="woricer.b4" 
outs=l datap<27Sk file="woiker.b4" 
out$=l data=275k riIe»"worker.b4" 
outs=l daia=27Sk file="woiker.M" 
outs=l data-27Sk file="woiker.b4" 
outs=:l data=275k nie="woiker.b4'' 
outs=l daia=27Sk file="worker.b4" 
outs>l data=27Sk file="worker.b4" 
outs^l datas275k file="worker.b4” 


!Port numbers 0... 3 for routers. 

IPort numbers 4 ... tor tasks(workers). 


place afserver 

host 

place fllta- 

mot 

place master 

foot 

place routeiO 

nxH 

place workeiOO 

nxH 

place workerOl 

loot 

place work«02 

root 

place wotkei03 

root 

place workei04 

root 

place workeiOS 

root 

place worker06 

root 

place worket07 

loot 

place woikerOS 

root 

place worker09 

root 

place wotkeiOlOO 

root 

place workeiOlOl 

root 

place router 1 

pi 

place workerlO 

pi 

place workerl 1 

pi 

place workerl2 

pi 

place workerl 3 

pi 

place woikerl4 

pi 

place worker IS 

pi 

place worker 16 

pi 

place woiko-n 

pi 

place woikerlg 

pi 

place workerl9 

pi 

place workerl 100 

pi 

place workerl 101 

pi 

place router 11 

Pll 

place woikerl 10 

Pll 

place workerl 11 

pll 

place workerl 12 

pll 


taskwotket21111113 
ta^ worker21111114 
task wo(ker21111115 
task waricer21111116 
ta^ wortcei21111117 
taskworkei2111111g 
task worker21111119 
taskwoiket2111111100 
task woiket2111111101 




place workerll3 

pll 

place workerl 14 

pll 

place worker! 15 

pll 

pljKe workerl 16 

pll 

place workerl 17 

pll 

place workffl 18 

pll 

place workerl 19 

pll 

place woikerl 1100 

pll 

place workerl 1101 

pll 


place routtrl 11 

pill 

place workerl 110 

pill 

place woikerllll 

pill 

place workerl 112 

pill 

place workerl 113 

pill 

place workerl 114 

pill 

place workerl 115 

pill 

place worko'l 116 

pill 

place workerl 117 

pill 

place workerl 118 

pill 

place workerl 119 

pill 

place workerl 11100 

pill 

place workerl 11101 

pill 

place routerl 111 

pill 

place workerl 1110 

pill 

place workerl 1111 

pill 

place workerl 1112 

pill 

place workerl 1113 

pill 

place workerl 1114 

pill 

place workCTl 1115 

pill 

place workwl 1116 

pill 

place workerl 1117 

pill 

place workerllll8 

pill 

place workerl 1119 

pill 

place workerl 111100 

pill 

place workerll 11101 

pill 

place routerlll 11 

pill 

place workwll 1110 

pill 

place worko'l 11 111 

pill 

place workerl 11112 

pill 

place workerlllll3 

pill 

place workerl 11114 

pill 

place workerl 11115 

pill 

place workerl 11116 

pill 

place worka-111117 

pill 

place workerl 111 18 

pill 

place workerll 1119 

pill 
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place workerl till 100 

plllll 

place woikerl 1111101 

plllll 

place routerl 11 111 

pllllll 

place workerl 111110 

pllllll 

place workerl 111111 

pllllll 

place workerl 111112 

pllllll 

place wcH'ka’l 111113 

pllllll 

place workerl 111114 

pllllll 

place workerl 111 115 

pllllll 

place workerl 111116 

pllllll 

place workerl 111117 

pllllll 

place woikerllllllg 

pllllll 

place workerl 111119 

pllllll 

place workerl 11 111 100 

pllllll 

place workerl 11 111 101 

pllllll 

place routerlllllll 

pllllll 

place workerl 1111110 

pllllll 

place workerl 1111111 

pllllll 

place workerl 11 111 12 

pllllll 

place workerl 1111113 

pllllll 

place workal 1111114 

pllllll 

place workwl 1111115 

pllllll 

place workerl 1111116 

pllllll 

place workerlllllll? 

pllllll 

place workwl 1111118 

pllllll 

place workerl 1111119 

pllllll 

place workerl 111111100 

pllllll 

place workerl 111111101 

pllllll 

place routBr2 

p2 

place worker20 

p2 

place worker21 

p2 

place workM22 

p2 

place worker23 

p2 

place worket24 

p2 

place worker25 

P2 

place worker26 

p2 

place worker27 

p2 

place worker28 

P2 

place worker29 

p2 

place worker2100 

p2 

place wotker2101 

P2 

place router21 

p21 

pl^ worker210 

p21 

place worker211 

p21 

place workor212 

P21 

place woikief213 

p21 


164 



place worker214 

p21 

place worker215 

p21 

place woiker216 

p21 

place wori£ei217 

p21 

place worker218 

p21 

place workw219 

p21 

place W(xker21100 

p21 

place worker2I101 

p21 

place router211 

p211 

place worker2110 

p211 

place wo(ker2111 

p211 

place wotkei2112 

p211 

place woiker2113 

p211 

place worket2114 

p211 

place wofker2115 

p211 

place worker2116 

p211 

place worker2117 

p211 

place woiker2118 

p211 

place worker2119 

p211 

place worfcerll 1100 

p211 

place woikef211101 

p211 

place router2111 

p2111 

place wotker21110 

p2111 

place w«ker21111 

p2111 

place worker21112 

p2111 

place woiker21113 

p2111 

place woiker21114 

p2111 

place wotker21115 

p2111 

place woiket21116 

p2111 

place worker2U 17 

p2111 

place worker21118 

p2111 

place worker21119 

p2111 

place worker2111100 

p2111 

place worker2111101 

p2111 

place router21111 

p21111 

place worker211110 

p21111 

place worker211111 

p21111 

placewort:er211112 

p21111 

place worker211113 

p21111 

place woikei211114 

p21111 

place worker211115 

p21111 

place worker211116 

p21111 

place worker211117 

p21111 

place wotker211118 

p21111 

place worker211119 

p21111 

place wofker21111100 

P21111 

place wo(ker21111101 

p21111 
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place router211 111 

p211111 

place worker2111110 

P211111 

place woiicer2111111 

p211111 

place worlcer2111112 

p211111 

place workef2111113 

p211111 

place wQrker2111114 

p211111 

place warkei211 Ills 

p211111 

place worker2111116 

P211111 

place worker2111117 

P211111 

place worker2111118 

P211111 

place worker2111119 

P211111 

place worker211111100 

P211111 

place woikei211111101 

P211111 

place router2111111 

p2111111 

pku:e workei21111110 

p2111111 

place woi1cer211 111 11 

P2111111 

place worker21111112 

P2111111 

place workCT21111113 

p2111111 

place woiker21111114 

P2111111 

place woikCT21111115 

P2111111 

place worker21111116 

p2111111 

place worke»21111117 

P2111111 

place worker21111118 

P2111111 

place woiker21111119 

p2111111 

place wotka2111111100 

P2111111 

place woiker2111111101 

p2111111 

connect 7 rfserver[0] 

MtertO] 

connect ? filter[0] 

afsaver[0] 

connect 7 filter[l] 

master[l] 

connect 7 mastCT[l] 

flltH^ll] 

connect 7 master[2] 

ioutei0[0] 

connect 7 routei0[0] 

master[2] 

connect 7 routei0[l] 

routerl[0] 

connect 7 routerllO] 

routeiOili 

connect 7 n)utei0[2] 

ft)uter2[0] 

connect 7 router2[0] 

routeiOci 

connect 7 iiouteiO(41 

woiket00t0[l 

connect 7 worket00[0] 

routei0[4] 

connect 7 routeiO[5] 

woikei01[0] 

connect 7 woikei01[0] 

routeiOlS] 
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connect ? routejO[6] 
connect ? woi1cei02[0] 

connect ? routei0[7] 
connect ? woiker03[0] 

connect ? routei0[8] 
connect ? woricei04[0] 

connect ? routei0[9] 
connect ? workeiO5(0] 

connect ? router0[10] 
connect 7 woikei06[0] 

connect ? routeiO[l 1] 
connect ? workei07[0] 

connect ? routeiO[12] 
connect 7 workei08[0] 

connect 7 routei0[13] 
connect 7 workei09[0] 


connect 7 routei0[14] 
connect 7 workei0100[0] 

connect 7 routei0[15] 
connect 7 workei0101[0] 


connect 7 routerl[l] 
connect 7 routerll[0] 

connect 7 routerl[4] 
connect 7 workerl0[0] 

connect 7 routerl[5] 
connect 7 woikerll[0] 

connect 7 routerl[6] 
connect 7 workerl2[0] 

connect 7 routerl[7] 
connect 7 worker 13 [0] 

connect 7 routerl[8] 
connect 7 workerl4[0] 


workei02[0] 

routet0[6] 

workei03[0] 

routei0[7] 

wotkCT04[0] 

routeiO[8] 

woiker05[0] 

routeiO[9] 

wotkei06(0] 

routei0[10] 

worker07(0] 

rDuteiO[ll] 

workeiO8[0] 

routeiO[12] 

woikeri)9[0] 

routeiO[13] 

woikeiOiOOEO] 

routeiO[14] 

workeiOlOlEO] 

n)uteiO[15] 


routerl 1[0] 
routerl[l] 

workerl0(0] 
routerl [4] 

woikerll[0] 
routerl[5] 

workerl2[0] 
routerl [6] 

workerl3[0] 
routerl[7] 

workerl4[0] 
routerl [8] 
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connect ? routerl [9] 
cwinect ? wotkerlSEO] 

connect ? routerl [10] 
connect ? workerl6[0] 

connect? routerl[ll] 
connect ? workerl7[0] 

connect ? routerl[12] 
connect 7 workerl8[0] 

connect ? routerl[13] 
connect ? workerl9[0] 

connect ? routerl [14] 
connect ? workerll00[0] 

ctmnect 7 ronterl[15] 
connect 7 wotkerl 101 [0] 


connect 7 routerl 1[1] 
connect 7 routerl 11 [0] 

connect 7 routerl 1 [4] 
connect 7 woikerl 10[0] 

connect 7 routerl 1 [5] 
connect 7 workerl 11[0] 

connect 7 routerl 1 [6] 
connect 7 woikerl 12[0] 

connect 7 routerl 1 [7] 
connect? workerl 13[0] 

c«inect?routerll[8] 
connect 7 workerl 14[0] 

connect? routerl 1 [9] 
connect 7 workerll5[0] 

connect 7 routerl 1[10] 
connect 7 workerl 16[0] 


connect 7 routerl 1 [11] 
cMinect 7 workerl 17[0] 


woikerl5[0] 
routerl [9] 

woikerl6[0] 
routerl [10] 

workerl7[0] 

routerl[ll] 

woikerl8[0] 

lOuterHlZ] 

woikerl9[0] 

iouterl[13] 

w«kwll00[0] 
routerl [14] 

woricerll01[0] 

routerl[15] 


routerl 11[0] 
routerll[l] 

workerl 10[0] 
routerl 1 [4] 

workerlll[0] 
routerl 1 [5] 

worko-lUlO] 
routerl 1 [6] 

w<»kwll3[0] 
routerl 1 [7] 

wotkerl 14[0] 
routerl 1 [8] 

workerl 15[0] 
routerl 1 [9] 

workerl 16[0] 
routerl 1[10] 


workerl 17[0] 
iouterll[ll] 
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connect ?routern[12] woricCTllSCO] 

connect ? workerl 18[0] routerl 1[12] 

connect? routerll[13] w«kerU9[0] 

connect ? workerl 19[0] routerl 1 [13] 

connect ? routerl 1[14] workerl 1100[0] 

connect ? workerl 1100[0] routerl 1[14] 

connect 7 routerl 1 [15] workerl 1101 [0] 

connect? workerl 1101[0] routerl 1[15] 


connect? routerl 11[1] routerllll[0] 

connect? routerl 111[0] iouterlll[l] 

connect ? routerl 11[4] workerl 110[0] 

connect ? workerl 110[0] routerl 11 [4] 

connect? routerl 11 [5] workerllll[0] 

connect ? workerl 111 [0] routerl 11 [5] 

connect ? routerl 11[6] workerl 11210] 

connect ? workerl 112[0] routerl 11[6] 

connect? routerl 11 [7] workerl 113[0] 

connect? workerl 113[0] routerlll[7] 

connect ? routerl 11 [8] workerl 114[0] 

connect ? workerl 114[0] routerl 11[8] 

connect? routerl 11 [9] workerl 115[0] 

ccmnect? workerl 115[0] routerl 11 [9] 

connect ?routerlll[10] workerl 116[0] 

connect ? workerl 116[0] routerl 11[10] 

connect? routerl 11 [11] workerl 117[0] 

connect? workerl 117[0] routerlll[ll] 

connect ? routerl 11 [12] workerl 118[0] 

connect? workerl 118[0] routerl 11[12] 

connect? routerl 11 [13] workerlll9[0] 

connect? workerl 119[0] routerl 11[13] 

connect? routerl 11 [14] workerl 11100[0] 

connect ? workwl 111()0[0] routerl 11 [14] 

connect ? routerl 11[15] workerl 11101[0] 

connect? workerl 11101 [0] routerlll[15] 



connect ? routerl 111 [ 1] 
connect ? routerl 1111 [0] 

routerllllUO] 

routerlllUl] 

connect 7 routerl 111 [4] 
connect ? woikerl 1110[0] 

workerl 1110[0] 
routerl 111[4] 

connect ? routerl 111 [S] 
connect 7 workerl 1111[01 

workerlllll[0] 
routerl 111[S1 

connect 7 routerllll[6] 
connect7 workerllll2[0] 

workerl 1112[0] 
routerl 111[6] 

connect 7 routerl 111 [7] 
connect7 woikwllllSP] 

workerllll3[0] 
routerl 111[7] 

connect 7 routerl 111 [8] 
connect 7 workerl 1114[0] 

woricwlllWlO] 
routerl 111[8] 

connect 7 routerl 111 [9] 
connect 7 workwl 1115[0] 

workerl 1115[0] 
touterllll[9] 

ccHinect 7 routerl 111 [ 10] 
connect 7 workerl 1116[0] 

workerl 1116[0] 
routerl 111[10] 

ccmnect 7 routerl 111[11] 
connect 7 woikerl 1117[0] 

workerl 1117[0] 
routerl llUUl 

connect 7 routerl 111[12] 
connect 7 workerl 1118[0] 

workerl 1118[0] 
routerllll[12] 

connect 7 routerl 111[13] 
connect 7 woikerl 1119[0] 

workerl 1119[0] 
routerllll[13] 

connect 7 routerl 111 [14] 
connect 7 workerl 111 100[0] 

workerlllll00[0] 

routerllll[14] 

connect 7 routerl 111[15] 
connect7 woik«1111101[0] 

workerl 111101 [0] 
routerllll[15] 

connect7 routerlllll[l] 
connect 7 routerl 11111 [0] 

routerllllllLO] 

routBrlllll[l] 

ccmnect 7 routerl 1111 [4] 
connect 7 workerl 11110[0] 

workerl 11110[0] 
routerlllll[4] 

connect 7 routerl 1111 [5] 
cwinect 7 woiter 111111 [0] 

workerl 1 111 1[0] 
routerllllUS] 
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connect’routerll 111[6] workerlllll2[0] 

connect? woricerl111 12[0] ixHUErlllll[6] 

CMinect? routerlllll[7] woricerlllll3(0] 

connect? workerlllll3[0] routerlllll[7] 

connect ? routerl 1111 [8] workerl 11114[0] 

connect ? workerl 11114[0] routerl 1111[8] 

connect ? routerl 1111[9] workerl 11115[0] 

connect? workerlllllS[0] routerl 1111[9] 

connect? routerl 1111[10] workerl 11116[0] 

ccxinect ? workerl 11116[0] routerl 1111 [10] 

connect ? routerlllll[ll] workerlllll7[0] 

connect ? workerl 11117[0] routerl 1111 [ 11] 

connect ? routerl 1111 [12] workerl 11118[0] 

connect ? wcwkerl 11118[0] routerl 1111 [12] 

connect ? routerl 1111 [13] workerl 11119[0] 

connect? workerl 111 19[0] routerl 1111[13] 

connect ? routerl 1111 [14] workerl 1111100[0] 

ccmnect ? workerl 1111100[0] routerl 1111[14] 

connect? routerlllll[15] workerl 1111101[0] 

connect ? workerllllll01[0] routerlllll[lS] 


connect ? routerl 11111[1] routerl 111111[0] 

connect ? routerl 111111 [0] routerl 11111 [1 ] 

connect ? routerl 11111[4] workerl 111110[0] 

connect ? workerl 111110[0] routerl 11111[4] 

connect ? routerl 11111 [S] workerl 111111 [0] 

connect ? workerl 111111 [0] routerl 11111 [5] 


connect ? routerl 11111[6] workerl 111112[0] 

connect ? workerl 111112[0] routerl 11111 [6] 

connect ? routerl 11111[7] workerl 111113[0] 

connect? woikwl 111 113[0] routerl 11111[7] 

connect ? routerl 11111 [8] workerl 111114[0] 

connect ? workerl 111114[0] routerl 11111[8] 
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connect? routerlll 11U9] wwkerllllll5[0] 

connect ? workerl 111115[0] roulerl 11111[9] 

connect? routerlll 111[10] woikerllllll6[0] 

connect ? workerl 111116[0] routerl 11111 [10] 

connect ? routerl 11111[11] woikerl 111117[0] 

ctmnect? woiterllllll7[0] routerllllll[ll] 

connect ? routerl 11111[12] woriterl 111118[0] 

connect? workerl 111118[0] routerlll 11U12] 

connect ? routerl 11111[13] woriterl 111119[0] 

connect ? workerl 111119[0] roulerl 11111 [13] 

ccmnect ? routerl 11111[14] woriterl 11111100[0] 

connect ? workerl 11111100[0] routerl 11111[14] 

connect ? routerl 11111[15] woriterl 11111101[0] 

ccmnect? workerl 111 11101[0] routerllllll[15] 


connect ? routerl 111111 [4] woriterl 1111110[0] 

connect? workerlllllll0[0] routerlllim[4] 

connect? routerlll 1111[5] workerllllllll[0] 

connect ? wotkerlllllllUO] routerl 111111[5] 

connect ? routerl 111111 [6] woriterl 1111112[0] 

ccmnect? woriterl 1111112[0] routerlllllll[6] 

connect ? routerl 111111[7] woriterl 1111113[0] 

connect? woriterll111 113[0] routerllll 111(7] 

ccmnect ? routerl 111111 [8] workerl 1111114[0] 

connect ? woriterl 1111114(0] routerl 111111 [8] 

connect ? routerl 111111 [9] workerl 1111115 [0] 

connect? woriterlllllll5[0] routerl 111111[9] 

connect ? routerl 111111(10] woriterl 1111116(0] 

connect? workerl 111 1116(0] touterll 11111(10] 

connect? routerlllllll[U] wQriterlllllll7[0] 

connect ? woriterl 1111117(0] routerl 111111(11] 

connect ? routerl 111111(12] workerl 1111118(0] 

connect ? workerl 1111118(0] routerl 111111(12] 

connect ? routerl 111111(13] woriterl 1111119(0] 

connect ? workerl 1111119(0] routerl 111111(13] 
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connect ? router 1111111 [ 14] workerl 111111100[0] 

connect? worko'll 111 111CI0[0] routwllllllUM] 

connect ? routerl 111111 [15] workerl 111111101 [0] 

connect? workerllllllll01[0] routerlllllll[15] 


connect ?routei2[l] iouter21[0] 

connect ? router21 [0] router2[ 1 ] 

connect ? router2[4] worker20[0] 

connect ? worker20[0] routei2[4] 

connect ? router2[51 worker21 [0] 

connect ? worker? 1[0] routet2[5] 

connect ? router2[6] workei22[0] 

connect ? worker22[0] router2[6] 

connect ? routei?[7] workei23[0] 

conna:t ? workei23[0] routei2[7] 

connect ? routei2[8] woik«24[01 

connect ? worker24[0] routei2[8] 

connect ? routet2[9] woikei25[0] 

connect ? worker25[0] routei2[9] 

connect ? router2[10] woiker26[0] 

connect ? worket26[0] routei2[10] 

connect ?routei2[ll] workei27[0] 

connect ? worker27 [0] ouiei2[ 11] 

connect ? routei2[12] worker28[0] 

connect ? worker28[0] router2[12] 

connect ? router2[13] workef29[0] 

connect ? worker29 [0] routei2[ 13] 

connect ? router2[14] woiker2100(0] 

connect ? worker2100[0] routef2(14] 

connect 7 routei2[lS] woikei2101[01 

connect ? woiker2101 [0] router2[l 5] 


connect? router? 1[1] router211[0] 

connect ? router211 [0] router21[l] 
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connect ? routei21[4] 
connect ? worker210[0) 

connect ? routei21[5] 
connect ? worker211[0] 

connect ? router21(6] 
connect ? worker212[0] 

connect ? routei21[7] 
connect ? worker213[0] 

connect ? router21[8] 
connect ? woiker214[0] 

connect ? routei21[9] 
connect ? worker215[0] 

connect ? router21[10] 
connect ? workei216[0] 

connect ?routei21[ll] 
connect ? worker217[0] 

connect ? router21[12] 
connect ? woiker218[0] 

connect ? routei21[13] 
connect ? worker219[0] 

connect ? router21[14] 
connect ? woikei21100(0] 


connect ?routei21 (15] 
connect ? worker21101(0] 


connect ?router211(1] 
connect ? routei2111(0] 

connect ? router211(4] 
connect ? worket2110(0] 

connect ? router211(5] 
connect ? workei2111 (0] 

connect ? toutei211 (6] 
connect ? worker2112(0] 

connect ? router211(7] 
connect ? worker2113(0] 


worker210(0] 

rDutei21(4] 

workef211(0] 

routei21(5] 

workei212(0] 

routei21(6] 

worker213(0] 

routei21(7] 

workei214(0] 

routei21(8] 

worker215(0] 

router21(9] 

workei216(0] 

router21(10] 

worker217(0] 

routei21[ll] 

workei218(0] 

routei21(12] 

wotkei219(0] 

routei21(13] 

workei21100(0] 
routei21(14] 

workei21101(0] 
routei21(15] 


routei2111(0] 

routei211(l] 

woiker2110(0] 
routei211[4] 

worker2111(0] 

routei211(5] 

worker2112(0] 

routei211(6] 

workei2113(0] 

routei211(7] 




connect ? router211[8] woiker2114[0] 

connect ? workw2114[0] roulei2l 1[8] 

connect ?router211 [9] woiker2115[0] 

connect ? workei2115[0] n)utei211[9] 

connect ? routei211[10] woi1ca2116[0] 

connect? worker2116[0] routei211[10] 

connect ?router211[ll] worker2117[0] 

connect? workei2117[0] router211[ll] 

connect 7 routei211[12] woiker2118[0] 

connect ? wotker2118[0] routBr211[12] 

connect ?n)utei211 [13] worket2119[0] 

connect? woricer2119[0] router211[13] 

connect ? routei211[14] workei211100[0] 

connect ? worker211100[0] routef211 [ 14] 

connect ? router211[15] workei211101[0] 

connect? worket211101[0] routei211[15] 


connect? routei2111[l] routei21111[0] 

connect ?routei21111[0] router2111[l] 

connect ? router2111[4] worker21110[0] 

connect? worker21110[0] router2111[4] 

connect ?routei2111[5] worket21111[0] 

connect? worker21111[0] router2111[S] 

connect ? routei2111 [6] workei21112[0] 

connect ? workei21112[0] routei2111[6] 

connect? routet2111 [7] worker21113[0] 

connect ? woiker21113[0] routei2111[7] 

connect ? router2111 [8] worker21114[0] 

connect ? workei21114[0] route(2111[8] 

connect ?routei2111 [9] workei21115[0] 

connect? worker21115[0] router2111[9] 


connect ?router2111[10] wotfcer21 U6[0] 

connect? worker21116[0] routet2111[10] 



connect ?routei2111[n] woikei21117[0] 

cwinect? woiker21117[0] roulei2111[ll] 

connect? routei2111[12] worker21 n8[0] 

connect? workei21118[0] Tou(ei2111[121 

connect? routet2111[13] woiket21 U9[0] 

connect ?woikei21119[0] toutei2111[13] 

connect? router2111[14] wotker2111100(0] 

connect ? worker2111100(0] routef2111(14] 

connect? router2111(15] worker2111101(0] 

connect? workei2111101(0] router2111[15] 


connect ? router21111(1] routei211111(0] 

connect? router211111(0] Foulei21111(l} 

connect ?router21111(4] woiker211110[0] 

connect? woTkei211110(0] routn21111[4] 

connect? routef21111(5] woiker211111[0] 

ccmnect? workCT211111[0] iDulei21111[S] 

connect? routei21111(6] woikei211112[0] 

ccmnect? worker211112[0] rout^llll[61 

connect ? routei21111 [7] wwkei211113[0] 

connect ?worker211113(0] rouiei21111[7] 

connect ?routei21111(8] woikei211114[0] 

ccmnect? worker211114(0] routei21111[8] 

cimnect?ioutei21111(9] worka211115(0] 

connect? woiket211115(0] routei21111(9] 

connect ? routei21111(10] wofkef211116(0] 

connect? worket211116(0] routei21111[10] 

connect ?routei21111(11] worker211117[0] 

connect? worket211117[0] roulei21111(ll] 

connect ?router21111(12] wofkei211118(0] 

connect ?worker211118(0] routei21111(12] 

connect ?routet21111(13] worker211119(0] 

connect? worker211119(0] roulet21111(13] 

connect ? roulei21111 [14] woiker21111100(0] 

ccmnect? woikei21111100[0] routei21111(14] 
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connect? routei21111[15] woriceT21111101[0] 

connect? woiker21111101[0] router2im[15] 


connect? roatei2111U[l] routei211111l[0] 

connect ?routei211111U0] router211in[l] 


connect ? routei211111[4] worker2111110(0] 

connect? worker2111110(0] routef211111(4] 

connect?routei211111(5] worker2111111(0] 

connect? woikei2111111(0] routei211111(5] 

connect ? routet211111(6] worker2111112(0] 

connect? workei2111112(0] rouier211111(6] 

connect? routei211111(7] woiker2111113(0] 

connect ? woika2111113(0] router211111(7] 

connect ? router211111 [8] wotker21 111 14(0] 

connect?workei2111114(0] routei211111(8] 

connect? router211111(9] w«'ker2111115(0] 

ctmnect? workei2111115(0] routet211111(9] 

connect ? router211111[10] worker2111116(0] 

connect? worker2111116(0] routei21 111 1(10] 

connect ?routei211111(11] woiker2111117(0] 

connect? workei2111117(0] routBi211111(11] 

connect ?routei211111( 12] worfcei2111118(0] 

connect? worker21 111 18(0] routei211111[12] 

connect ? routei211111(13] woikei2111119(0] 

connect? worker2111119(0] router211111(13] 

connect ? n)utet211111(14] workei211111100(0] 

connect ? woiket211111100(0] routei211111 (14] 

connect ? routei211111(15] woiker211111101(0] 

connect ? worker211111101(0] routei211111(15] 


connect ? routei2111111 (4] worker21111110(0] 

connect ? woikei21111110(0] routei2111111(4] 

connect ? routei2111111(5] worker21111111(0] 

connect? wotker21111111(0] router2111111(5] 
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connect ?router2mill[6] worta!t21111112I0] 

c<mnect?WMte21111112[0] router21inil[61 

connect ?routei2111111 [7] wotkei21111113[0] 

connect? worltet21111113[0] toutei2Illlll[7] 

connect? router2111111[8] woik«21111114[0] 

connect? workef21111114[0] roniei2111111[8] 

crainect ? router2111111 [9] workei21111115[0] 

connect ? worlcei21111115[0] rouiei2111111[9] 

connect ? routei2111111 [ 10] worker2111111610] 

cwtnect? worlc«21111116[0] routei2111111[10] 

connect ? routei2111111 [ 11 ] worker! 1111117[0] 

connect ? workea21111117[0] routet2111111 [ 11] 

connect ? touter2111111[12] woiker21111118[0] 

connect ? worker21111118[0] routei2111111[12] 

connect ? router2111111[13] woikei21111119[0] 

connect 7 worker! 1111119[0] router2111111(13] 

connect ? router!! 11111(14] worker!! 11111100(0] 

connect ? worker!! 11111100(0] routei2111111 (14] 

connect ? router!! 11111(15] worka!! 11111101(0] 

connect ? worker! 111111101 (0] router!! 11111(15] 

bind input master(4] values&8000001C !Link3 

bind output niaster(4] value=&8000000C 
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APPENDIX C - SOURCE CODE FOR READING TERRAIN DATA 


This appendix contains the source listings of the C code developed for reading a block 
of terrain data from PEGASUS database into a specified buffer location which is stored in 
SUN memory. The source code is stored in files as listed below: 

1. PVG_DEC.H 

2. PVG_DEC.IN 

3. PVG.DEF.IN 

4. get_teiT.c 
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#ifndef PVG_INCLUDED 
#define PVG.INCLUDED 


FILENAME: PVG_DEC.H 

PURPOSE: GLOBAL PARAMETER DECLARATION FILE FOR PVG ALGORITHMS 

DESCRIPTION: The PVG_DEC.H include file includes all global variables 
required for sharing data between major software components of 
PVG software. 

Parameters are divided into major categories using asteric lines. 

All global variables shall be ALL CAPITAL letters. 

USE EXAMPLE: 

#include “PVG.DEC.H” 

*..**,.**.„***„,***,,„**,CODESTART*****»************»**************/ 

#include “PVG.DEF.IN” 

;»****.*«****.**** COLOR PARAMETERS DECLARATIONS***********************/ 

/.♦•*.**,*****.*„*«TEiy^;^ D^^TA base DECLARATIONS********************/ 

/* Sun main memory terrain storage buffers*/ 
u_int TERRAINl[MAX_BLOCKl][BLOCKl_SI2:E]:/*one meter 
terrain buffer*/ 

/* Terrain data bit assignments valid for all resolutions: 

32 1 

10987654321098765432109876543210 
IELE I SPARE I NOR ISIVEGIGSV I 

ELE = elevation from sea level to top of vegetation in meters 

SPARE = not used 

NOR = 4 bit surface normal 

S = sun shade bit 

GSV = gray shade value 
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inlTERRAINMAP[MAX_EAST_BLOCK][MAX_NORTH_BLOCK]/* terrain map 
contains pointers to terrain data blocks*/ 

int HAVEMAP[MAX_EAST_BL0CK][MAX_N0RTH_BL0CK]/* Terrain resolution 
map tells what resolution blocks are in memory*/ 


/* range resolution parameters */ 

int SRMIN[RES_RANGE_NUM]/*minimum resolution in meters */ 
int SRMAX[RES_RANGE_NUM];/*maximum resolution in meters*/ 
int SRSTEP[RES_RANGE_NUM];/* step size in meters*/ 


/* HSPVG terrain data management */ 

int IF0VGRID[MAX_EAST_BL0CK][MAX_N0RTH_BL0CK];/* Terrain grid 
to image map. Specifies the image location of 
ground points. 

EX; IF0VGRID[E][N1= image i coordinate 
in upper word 
»image j (row) coordinate 
in lower word 
= -1 if terrain point is not 
in the IFOV image*/ 

/* HSPVG terrain data communication variables*/ 

u_shortTER_PROC_HAS[MAX_EAST_BLOCK][MAX_NORTH_BLOCK] 
[RAY_PROC_MAX][RES_RANGE_NUM]/*Map of terrain 
in the HSPVG ray trace processors. 

Dimensions are; 

-easting quarter kilometer block numbers 
-northing quarter kilometer block numbers 
-ray processor number 
-resolution ranges 

for ea:h resolution range a 16 bit value is stored 
with the following meaning 
bit 15 BitsOtoM description 
0 Ono data no need 
1 Ono data but needs it 
0 blockfhas data no need 
1 block# has data and needs it 



u_shortTER_PROC_SEND[RAY_PROC_MAX+l][MAX_BLOCK64][4]; 
/* Terrain processor send list Dimensions are 
-HSPVG processor number were data is to come from 
0= SUN processor 
-list entry index sized to allow a full 
of every quarter kilometer 
[][][0]-destination processor number 
if -1 means delete this terrain data 
nn[l]-easting block number of data to be sent 
OD [2]-northing block number of data to be sent 
[]n[3]-resolution of data to be sent*/ 

u_short SEND[RAY_PROC_MAX+l]:/* list entry pointer for 
TER_PROC_SEND contains the number of blocks 
each processor needs to send. 


data base DECLARATIONS* 
int TARGETLIST[MAX_TARGETS][10]i'* target informauon list 
[0]=target type ID 

[1] =easting position of target in meters 

[2] =northing position of target in meters 

[3] =altitude position of target in meters 

[4] = target heading in millirads clockwise from northing 

[5] = target pitch in millirads positive up 

[6] = target roll in millirads clockwise positive 

[7] = speed in millimeters/sec 

[8] = status 

[9] = spare configuration parameter*/ 
struct HAVEUSTEL 1 

unsigned char *TAR_PTR: /* pointer to target data in memory */ 
int RES: /* resolution index of target data */ 

I HAVELIST[MAX_TARGETS]; /* list of data in SUN memory */ 

/*SUN resident target file buffers. These buffers are sized to hold 
entire target file for a binary write*/ 
unsigned charTARBUFl[MAX_TARl][TARl_SIZE]; 




/* I’s resolulion SUN resident target buffo- */ 
unsigned char TARBUF2[MAX_TAR2][TAR2_S1ZE]; 

/* 2’nd resolution SUN resident target buffo •/ 
unsigned charTARBUF3[MAX_TAR3][TAR3_SIZE]; 

/* 3’d resolution SUN resident target buffer •/ 
unsigned char TARBUF4[MAX_TAR4][TAR4_SIZE]; 

/* 4’th resolution SUN resident target buffo */ 

int TAR_SEND_LIST[MAX_TARGETS][4];/* Ust of data to be sent to the 

target processor 

[0]=source of dau processor ID 

[1] =destination of data processor ID 

[2] =souTce data start address of data packet (UNUSED) 

[3] =numbo of data elements to send*/ 

unsigned char *TAR_SEND_UST_PTR[MAX_TARGETS]: 

/• replaces [2] of above */ 

int TAR_HAVE_LIST[MAX_TARGETS][20]y* infomation block buffo 
used to collect and store information about what data 
the target processor has. 

[0]=target type ID 
>0 target type ID 

<0 player not needed or not in field of view 

[1] =easting position of target in meters 

[2] =notthmg position of target in meters 

[3] =a!titude position of target in meters 

[4] = target heading in miliiradians clockwise from northing 

[5] s target pitch in miliiradians positive up 

[6] s target roll in miliiradians clockwise positive 

[7] = speed in meters/sec 

[8] = status 

[9] = spare configuration parameter*/ 

/*[10]=data transfer instruction parameter 
=0 no change 

=1 delete old view data 

=2 delete old view data and add new data 

[11] =view resolution 

[12] =resolution linear array dimension 

[13] =view heading miliiradians 

[14] =vlew pitch miUiradians 

[15] =view roll miliiradians 
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[16] = image center in column ]»els, i 

[17] = image center in row {rixels, j 

[18] = image scale in pixels per millimeter 

[19] = spare view parameter*/ 

int NUM_TAR_TRIAL; /• number of targets in trial */ 


and flight declarations******* 

int FLIGHT_CHAR[10]:/* Missile flight characteristics 
[0]= flight speed in meters per second 

[1] stum rate in degrees per second 

[2] =Iaunch acceleration in meters/sec/sec 

[3] to [9] = undefined*/ 

int 1FOVNOW[10]/*' instantaneous field of view vector 
[0]=easting position of camera in meters 

[1] =northing position of camera in meters 

[2] =altitude position of camera relative to sea level 

[3] =boresight direction heading clockwise from 
northing axis(milliradian$) 

[4] =boresight direction pitch positive up from 
horizontal planefmilliradians) 

[5] =field ol view roll about boresight vector 
clockwise positive looking out/milliiads) 

[6] =zoom factor in milliradians 
[71=curser location, x pixels in upper word 
y pixels in Iowa" word 

[8] =auto pilot control status, 

0=pie launch 

l=launch under auto pilot control 
2=fUght under auto pilot control 
3=flight no autopilot 
4=flight lock on target 
5=crash no signal 

[9] = spare*/ 
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int IFOV_PREDICT[PREDICT_INT_MAX][8];/* IFOV predict matrix 
[0]=easting position of missile in meters 

[1] =northing position of missile in meters 

[2] =altitude position of missile in meters 

[3] = easting velocity direction cosine 

[4] = noithing velocity direction cosine 

[5] = vertical velocity direction cosine 

[6] = speed in meters/sec 

[7] = autopilot control status 
0=pre launch 

l=launch under auto pilot control 
2=flight under auto pilot control 
3=flight no autopilot 
4=flight lock on target 
S^crash no signal*/ 

int PREDICT_W[PREDICT_INT_MAX];/* Predict interval 
array in seconds. */ 

int WAYP0INTS[WAYP0INT_MAX][3]/* point coordinate vectois*/ 

int LOCK_POS_IMAGE[3]; /* target lock position and status in 
image coordinates returned to PVG from flyout model 
[0] = pixel row count 

[1] = pixel column count 

[2] = lock status <0 not locked, >0 locked*/ 

int LOCK_POS_UTM[4]: /* target or terrain position and status 
of locked on pixel location sent to flyout model 
from PVG in UTM coordinates 
[0]= easting in meters 

[1] = northing in meters 

[2] = altitude in meters from sea level 

[3] = miss distance from closest target if zero lock 
on identified target otherwise it is locked on 

a terrain feature*/ 
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►•OUTPUT IMAGE PARAMETERS DECLARATIONS" 


int OUTPUT_IMAGE[PVG_HEIGHTl[PVG_WIDTH]:/* output image buffer 

bits 0 to 7 red 

bits 8 to 15 green 

bits 16 to 23 blue 

bits 24 to 31 alpha*/ 

/* TfflS WILL NOT WORK!! YOU PLOT A COLOR INDEX, NOT AN RGB VALUE. •/ 

short RAY_SEG[RAY_PROC_MAX](4]:/* ray trace calculation image 

window definitions the first dimension is the 

processor number, the four parameters represent 

0= lower left tow 

1= lower left column 

2= upper right row 

3= upper right column*/ 

u_short TAR_OUT[PVG_HEIGHT][PVG_WIDTH][2); 

/• Target PVG output array 
[0]« gray shade 
[1]= slant range*/ 

int TER_OUT[PVG_HEIGHT][PVG_WIDTH][2]; 

/• Terrain PVG ray trace output array 
[0]* terrain data base element 
[1]= slant range*/ 

u_char RLUTfRLUT_B YTES];/* Rendering lookup table converts terrain 
data base and environmental parameters to gray shade*/ 

u_char ATrLUT[ATrLUT_BYTES];/* Attmospheric attenuation lookup*/ 

y*..****..********.«.^,^jj,jjSTRATIVE SOFTWARE DECLARATIONS*************/ 
/**.****.***..**...**^jg(^40RY management DECLARATIONS*******************/ 

^*****,****.*.***.***T^(;; board PAR/tMETERS DECLARATIONS**************/ 

hardware PARAMETERS DECLARATIONS**********/ 

fendif 
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#ifndef PVO_INCLUDED 
#derine PVG_INCXUDED 


FEJENAME: PVG.DEC.IN 

PURPOSE; GLOBAL PARAMETER DECLARATION FE,E FOR PVG ALGORITHMS 

DESCRIPTION: The PVG_DEC.IN include file includes all global variables 
required for sharing data between major software components of 
PVG software. 

Parameters are divided into major categories using asteric lines. 

All global variables shall be ALL CAPITAL letters. 

USE EXAMPLE: 

#include <PVG_DEC.IN> 

,*,,.*.*...*...*.»****..**.*CodESTART**********«*****»* 

#include“PVG_DEF.IN” 

COLOR PARAMETERS DECLARATIONS***** 

/,.*.*.*.*****.**.**TErrAIN data base DECLARATIONS********************/ 

/* Sun main memory terrain storage buffers*/ 

extern u_intTERRAINl[MAX_BLOCKI][BLOCKl_SIZEiy*one meter 
terrain buffer*/ 

/* Terrain data bit assignments valid for all resolutions: 

321 

10987654321098765432109876543210 
IELE I SPARE I NOR ISIVEGIGSVI 



ELE = elevation from sea level to top of vegetation in meters 

SPARE = not used 

NOR = 4 bit surface normal 

S = sun shade bit 

GSV = gray shade value 
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extern int TERRAINMAPP^lAX_EAST_BLOCK][MAX_NORTH_BLOCK];/* tenain map 
contains pointers to terrain data blocks*/ 

ext«n int HAVEMAPIMAX_EAST_BLOCK][MAX_NORTH_BLOCK],/* Tenain resolution 
mq) tells what resolution blocks are in memory*/ 


/* range resolution paramems */ 

extern int SRMIN[RES_RANGE_NUM]-y*minimum resolution in meters */ 
extern int SRMAX[RES_RANGE_NUM];/*maximum resolution in meters*/ 
extern int SRSTEP[RES_RANGE_NUM]:/* step size in meters*/ 


/* HSPVG terrain data management */ 

extern intIFOVGRID[MAX_EAST_BLOCK](MAX_NORTH_BLOCKly» Terrain grid 
to image map. Specifies the image location of 
ground points. 

EX: IFOVGRID[E][N]= image i coordinate 
in upper word 
= image j (row) comlinate 
in lower word 
= -1 if tenain point is not 
in the IFOV image*/ 


/* HSPVG terrain data communication variables*/ 

extern u_short TER_PROC_HAS[MAX_EAST_BLOCK]IMAX_NORTH_BLOCK] 
[RAY_PROC_MAX][RES_RANGE_NUM]y*M^ of tenain 
d^ in the HSPVG ray trace processors. 


-easting quarter kilometer block numbers 
-northing quarter kilometer block numbers 
-ray processor number 
-resolution ranges 

for each resolution range a 16 bit value is stored 
with the following meaning 
bit 15 BitsOtoU description 
0 Ono data no need 
1 Ono data but needs it 
0 blockihas data no need 
1 block# has data and needs it 
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extern u_short TER_PROC_SEND[RAY_F»OC_MAX+l]{MAX_BLOCK64][4]: 

/* Twrain processor send list Dimensions are 

-HSPVG processor number were data is to come fiom 

0= SUN processor 

-list entry index sized to allow a full 

of every quarter kilometer 

n[][0]-deslination processor number 

if -1 means delete this terrain data 

|;][][I]-easting block number of data to be sent 

[][] [2]-northing block number of data to be sent 

[][][3]-resolutlon of data to be sent*/ 

extern u_shott SEND[RAY_PRC)C_MAX+1];/* list entry pointer for 
TER_PROC_SEND contains the number of blocks 
each processor needs to send. 


/»****..*****.*,**..jarget data base declarations*****' 

extern int TARGETLIST[MAX_TARGETS][10]i^* target information list 
[Ojsstarget type ID 

[l}=easting position of target in meters 

[2] =sncathing position of target in meters 

[3] =altitude position of target in meters 

[4] = target heading in millirads clockwise from northing 

[5] = target pitch in millirads positive up 

[6] = target roll in millirads clockwise positive 

[7] = speed in millimeters/sec 

[8] = status 

[9] = spate configuration parameter*/ 
extern struct HAVELISTEL ( 

unsigned char *TAR_PTO: /• pointer to target data in memory */ 
int RES; /• resolution index of target data */ 

) HAVELIST[MAX_TARGETS]; /* Ust of data in SUN memory */ 

/*SUN resident target file buffers. These buffers are sized to hold 

entire target file for a binary write*/ 

extern unsigned char TARBUFl[M/kX_TARl]rrARl_SEZE]; 





/* I’s resolution SUN resident target buffer •/ 

extern unsigned char TARBUF2[MAX_TAR2]rrAR2_SIZE]: 

/* 2’nd resolution SUN resident target buffer */ 

extern unsigned char TARBUF3[MAX_TAR3]rrAR3_SIZE]: 

/* 3’d resolution SUN resident target buffer */ 

extern unsigned char TARflUF4[MAX_TAR4]rrAR4_SIZE]: 

!* 4*th resolution SUN resident target buffer */ 

extern int TAR_SEND_LIST[MAX_TARGErS](4]-y* list of data to be sent to the 

target processor 

[O]=source of data processor ID 

[ll=de$tination of data processor ID 

[2] =source data start address of data packet (UNUSED) 

[3] =number of data elements to send*/ 

extern unsigned char *TAR_SEND_UST_PTR[MAX_TARGETS]: 

/* replaces [2] of above ♦/ 

extern intTAR_HAVE_LIST[MAX_TARGETS][20]:/* information block buffer 
used to collect and store information about what data 
the target processor has. 

[Oj^target type ID 
>0 target type ID 

<0 player not needed or not in field of view 

[1] «easting position of target in meters 

[2] snorthing position of target in meters 

[3] =altitude position of target in meters 

[4] s target heading in milliradians clockwise from northing 

[5] = target pitch in milliradians positive up 

[6] = target roll in milliradians clockwise positive 

[7] = speed in metos/sec 

[8] = status 

[9] = spme configuration parameter*/ 

/*[10]=data transfer instruction parameter 
=0 no change 

=1 delete old view data 
=2 delete old view data and add new data 
[ 11 ]=vie w resolution 
I12]=iesolution linear array dimension 

[13] =view heading milliradians 

[14] =view pitch milliradians 

[15] =view roll milliradians 
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[16] = image center in column pixels, i 

[17] = image centw in row pixels, j 

[18] = image scale in pixels per millimeter 

[19] = spare view parameter*/ 

extern int NUM_TAR_TRIAL; /* number of targets in trial ♦/ 


y»***,*****.**.**».*CAMERA AND FLIGHT DECLARATIONS 

extern int FLIGHT_CHAR[10]/* Missile flight characteristics 
[0]= flight speed in meters per second 

[1] =tum rate in degrees per second 

[2] =launch acceleration in meters/sec/sec 

[3] to [9] = undefined*/ 

extern int IFOVNOW[10]V* instantaneous field of view vector 
[0]=easting position of camera in meters 

[1] =northing position of camera in meters 

[2] =altitude position of camera relative to sea level 

[3] =boresight direction heading clockwise from 
northing axis(milliradians) 

[4] =baresight direction pitch positive up from 
horizontal plane(milUradians) 

[5] =fleld of view roll about boresight vector 
clockwise positive looking outfmilliiads) 

[6] =zoom factor in miliiradians 
I7]=curser location, x pixels in upper word 
y pixels in lower word 

[g]=auto pilot control status, 

0=pre launch 

l=launch under auto pilot control 
2=flight under auto pilot control 
3=fUght no autopilot 
4=fUght lock on target 
5=crash no signal 
[9]= spare*/ 
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extern int IFOV_PIffiDICT[PREDICr_INT_MAX][8];/* IFOV predict matrix 
[0]=easting position of missile in meters 

[1] snoithing position of missile in maets 

[2] =altitude position of missile in meters 

[3] = easting velocity direction cosine 

[4] = northing velocity direction cosine 

[5] = vertical velocity direction cosine 

[6] = speed in meters/sec 

[7] = autopilot control status 
0=pre launch 

Islaunch under auto pilot control 
2^flight under auto pilot control 
3=i1ight no autopilot 
4=flight lock on target 
5=cradt no signal*/ 

extern int PREDICT_Ihrr[PREDICr_INT_MAX];/* Predict interval 
array in seconds. •/ 

extern int WAYPOINTS[WAYPOINT_MAX][3];/* point coordinate vectors*/ 

ext . int LOCK_POS_IMAGE[3]: /• target lock position and status in 
iir.if; coordinates returned to PVG from flyout model 
[0 pixel row count 

[1] = pixel column count 

[2] = lock status <0 not locked, >0 locked*/ 

extent int LOCK_POS_UTM[4]; /• target or terrain position and status 
of locked on pixel location sent to flyout model 
ftom PVG in UTM coordinates 
[0]» easting in metas 

[1] = northing in meters 

[2] = altitude in meters from sea level 

[3] s miss distance from closest target if zero lock 
on identified target otherwise it is locked on 

a terrain feature*/ 
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•OUTPUT IMAGE PARAMETERS DECLARATIONS* 


extern int OUTPUT_IMAGE[PVG_HEIGErn[PVG_WIDTH]y* output image buffer 

bits 0 to 7 red 

bits 8 to 15 green 

bits 16 to 23 blue 

bits 24 to 31 alpha*/ 

/* THIS WILL NOT WORK!! YOU PLOT A COLOR INDEX. NOT AN RGB VALUE. ♦/ 

extern short RAY_SEG[RAY_PROC_MAX][4];/* ray trace calculation image 
window definitions the first dimension is the 
processor number, the four parameters represent 
0= lower left row 
1= lower left column 
2= upper right tow 
3= upper right column*/ 

extern u_short TAR_OUTtPVG_HElGHT][PVG_WIDTH][2]; 

/* Target PVG output array 
[0 ]b gray shade 
[1]» slant range*/ 

extern int TER_0UT[PVG_HEIGHT1[PVG_W1DTH][2]; 

/* Terrain PVG ray trace output array 
[0 ]k terrain data base element 
[1]= slant range*/ 

extern u_charRLUT[RLUT_BYTES];/* Rendering lookup table converts terrain 
data base and environmental parameters to gray shade*/ 

extern u_char ATTLUT[ATTLUT_BXTES]/* Attmospheric attenuation lookup*/ 

/*,,„..*************^Mi,flS-pRAjIVE SOFTWARE DECLARATIONS*************/ 
/********,***********j^MORY MANAGEMENT DECLARATIONS*******************/ 

;*.*,***,..,***,.*,**».rAAc BOARD PARAMETERS DECLARATIONS**************/ 

/*,*..**.*,****.***..*HSPVG HARDWARE PARAMETERS DECL/VRATIONS**********/ 

#endif 
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tifndef PVG_DEF_INCLUDED 
#<Jefine PVG_DEF_INCLUDED 

FILENAME: PVG_DEF.LARGE 

PURPOSE: GLOBAL PARAMETER DEFINITION FILE FOR PVG ALGORITHMS 

DESCRIPTION: The PVG_DEF.IN include file includes all global constants 
required for defining global constants used by PVG software 
components. 

Parameters are divided into major categories using astetic 
lines. 

All global constants shall be ALL CAPITAL letters. 

USE EXAMPLE: 

#include “PVG.DEF.IN" 

in your directory link to Aiome/fogm/include/PVG_DEF.IN 

....,«.*...*,**....,*,*.,«.CODESTART****»****************************/ 

#include <FOGM/stdef.h> /* standard definitions •/ 

/*#include “stdef.h’^/ 

#include <sys;/types.h> 


/.*...*****„*«,*. COLOR PARAMETERS DECLARATIONS***********************/ 
/.***.*,****.**,,.**T^jy^^ gy^SE DECLARATIONS********************/ 


/* Sun main memory terrain storage buffers*/ 

/* terrain data blocks all cover a 256meterx256 meter area*/ 

#defme MAX_BLOCKl 4 /* # one meter terrain BLOCKl_SIZE*4byte blocks*/ 
#defme BLOCKl_SIZE 65536 /» # elements in 1 meter block */ 

#defme MAX_BLOCK4 1024 /* # 4 meter terrain BLOCK4_SIZE*4byte blocks*/ 
#define BLOCK4_SIZE 4096 /* # elements in 4 meter block */ 

#defme MAX_BLOCK16 14336 /* # 16 meter terrain BLOCK16_SlZE*4byte blocks*/ 
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#defme BL0CK16_SIZE 256 /• # elements in 16 meter block */ 


#define MAX_BLOCK64 14336 /* # 64 meter terrain BLOCK64_SIZE*4byte blocks*/ 
#defme BLOCK64_SIZE 16 /• # elements in 64 meter block */ 

#clefine MAX_BLOCK256 14336 /• # 256 meter terrain 4byteblocks*/ 

#defme MAX_EAST_BLOCK 128 /* # 256 meter blocks in east direction*/ 

#defme MAX_NORTH_BLOCK 112/*# 256 meter blocks in north direction*/ 

tdefine MIN_EAST_irrM 43328 /* lower left hand comer of data base UTM east*/ 
fdefme MIN_NORTH_irrM 63904 /• lower left hand comer of data base UTM north*/ 

/* Range resolution parameters */ 

#defme RES_RANGE_NUM 4 /* # resolution ranges */ 

/• Resolution codes */ 

#defme RESOLUTION.! 0 
#defmeRESOLUTION_4 1 
#denne RESOLUnON_16 2 
#denne RESOLUnON_64 3 

DATA BASE DECLARATIONS*********************/ 

/* SUN target data buffers*/ 

idefine MAX.TARGETS 256/* Maximum number of targets in PVG*/ 

#defme MAX.TAR.TYPE 32/*Maximum number of different targets*/ 

#defme MAX.TARl 8/* Maximum number of target types in 1 ’st 
resolution level*/ 

#defme MAX_TAR2 8/* Maximum number of target types in 2’nd 
resolution level*/ 

tdefme MAX_TAR3 8/* Maximum number of target types in 3’d 
resolution level*/ 

#defuie MAX_TAR4 8/* Maximum number of target types in 4’th 
resolution level*/ 

#deRne TARl.SEZE 1069056/* Buffer size in bytes for 64pictutBS of I’st 
resolution level*/ 

#define TAR2.SIZE 282624/* Buffer size in bytes for 64 pictures of 2’nd 
resolution level*/ 

#defme TAR3_SIZE 86016/* Buffer size in bytes fw 64 pictures of 3’d 
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resolution level*/ 

#define TAR4_SIZE 36864/* Buffer size in bytes for 64 pictures of 4’th 
resolution level*/ 


/.♦...♦♦.♦.•♦♦♦♦♦♦♦♦camera and fught declarations********************/ 

#defme PREDICT_1NT_MAX 4 /* Number of IFOV i»edict intervals*/ 

#define WAYPOINT_MAX 20 /* Maximum # way point cotx’dinate vectors*/ 

/..♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦.♦output image PARAMETERS DECLARATIONS**************/ 

#deftne PVG_HEIGHT 256 /* output image # pixel rows*/ 

#derme PVG_WIDTH 256 /* output image #pixel columns*/ 

#defme PVG_PIX_SIZE 65536 /• output image size in pixels*/ 

#defme RLUT.BYTES 2097152 /* # bytes in the RLUT*/ 

#define RLUT.BIT.SIZE 21 /* # bits in RLUT input addess*/ 

#define VIEW_INDEX_SI2E 3 /*# bits in view vector of the RLUT input address*/ 

#defme NORM_INDEX_SIZE 4 /*# Wts in surf^e normal of the RLUT input address*/ 

#defme ATTLUT.BYTES 2097152 /•# bytes in attenuation table ATILUT*/ 

#defme ATTLUT_BIT_SIZE 21 /* # bits in ATILUT input address*/ 

#defme TAIL.VIS_MASK 255 /*if target gray shade is 255 let background through */ 

/♦.♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦.♦♦administrative software DECLARATIONS*************/ 

fdefme D2R 0.0174532 f degrees to radians */ 

#defme D2MR 17.4532 /* degrees to mUliradians */ 

#defme R2D 57.295827 /* radians to degrees */ 

#defme MR2D 0.057295827 /* mUliiadians to degrees */ 

/♦♦♦♦♦♦♦.♦....♦♦♦♦♦..j^jg^jORY MANAGEMENT DECLARATIONS*******************/ 
#defme MAX_SEND 14336 /* maximum number of messages in 
TER_PROC_SEND */ 


/** 


*TAAC BOARD PARAMETERS DECLARATIONS**************/ 
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►HSPVG HARDWARE PARAMETERS DECLARATIONS* 


#define RAY_PROC_MAX 1 /* maximum # ray nace processors */ 
#define TAR_PROC_MAX 1 1* maximum # target processors */ 


iendif 
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^ (C) Copyright Nascent Systems Development Inc. 1991 

' Developed under contract DABT62-90-C-0006. Subcontract CSC/ATD-WR-FO-0101 


FILENAME: getjerr 
AUTHOR: J.R. Aldn, August 1989 

PURPOSE: Read a Mock of terrain data into a specified buffer location 
which is stored in SUN main memory. The block needed has a 
lower-left coma' at DB coordinates x, y. 

DESCRIPTION: 

Opening and closing files eats up a lot of time. Ideally, this function 
should open up every file at start-up but it can’t because the number of 
files that can be opened at one time is 60 and the number of PVDB files 
is 83. Since other functions will t^n up who-knows-how-many files. I’ve 
set the open file limit to MAXJFILE.HANDLES, an arbitrary value. Files 
are opened and usage statistics maintained until the file handle list is 
exhausted, at which point the least often used file is closed, and a new 
file is opened to take its place. 

Instead of using time-wasting string comparisons for file opens, a list 
of hash values for file names is maintained. The hash value for a file 
is computed as: 

hash_value = (tBsolution_code « 8) I tile_number 

TMs way, time can be saved by not using nested “iC statements to 
determine disk partition numbers. 

Processing Steps: 

make sure the x,y coordinates ate in bounds 
based upon the resolution code 
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( 

compute the block length 

set the data block pointer to the starting address of the 
amtropriate (global) TERRAIN buffer 
compute the tile number 
compute the block number 
) 

compute the hash value based upon the tile and block number 

if the file with this hash value is already open 

{ 

get the file handle for it 

increment the number of times this file handle has been used 

1 

{ 

find least used file handle 

if there is already an open file associated with it 
close the file 

open a new file for this file handle index 

set number of times file handle has been used to 1 

) 

compute file offset for block number 
seek to that file offset 

compute the number of bytes that need to be read 
read the block into the array referenced by bufindex 
return numbw of elements successfully read 
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RETUiRN VARIABLE; Returns numbra- trf elen 


.else ERROR. 


REQUIRED INCLUDE FEES: 

PVG_DEC.IN 

PVG_DEF.IN 

LIBRARIES REQUIRED: 

INPUT/OUTPUT FILES: use name description 

EXTERNAL PARAMETERS: use name include descripdon 


Sun main memory terrain storage buffers (declared in PVG_DEC.IN) updated 
by get_terT() and called by tstwter.c. MAX_BLOCK sizes are declared in 
PVG_DEF.IN. 

lOTERRAINl [MAX_BLOCKl] [BLOCKl.SIZE] 

10 TERRAIN4 (MAX_BL0CK4] {BL0CK4_SIZE] 

10 TERRAIN16 [MAX_BL0CK161 [BLOCK 16_SIZE] 

IOTERRAIN64 [MAX_BLOCK64] [BLOCK64_SIZE] 

FUNCnONS/SUBROUTINES CALLED: None. 

USAGE EXAMPLE: 


get_terr_siat« getjerr( RESOHJTION_l, x, y, buflndex ); 

This call reads a quarter kilometer (block) of 1-meter data at location 
index x.y and puts it into TERRAINn[buflndex]. 
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“CODE START*" 


#include “PVG_DEF.IN” 

#include“PVG_DEC.IN" 

#include <stdlo.h> 

#include <fcntl.h> t* for binary I/O */ 

#defme MAX_FILE_HANDLES 32 

#define MAX_PVDB_FILES 83 
#define MAX_FILE_NAME_LEN 32 

#define MAX_PVDB_EAST 32767 
#define MAX_PVDB_KORTH 28671 

#define UNUSED-1 

int get_terr( res_code, x, y, bufindex) 

int res_code: /* Resolution; 1,4,16, or 64 •/ 
int X, y: /* terrain map coordinate indices */ 
int bufmdex; /* buffer index of block to be read */ 

( 

extern unsigned intTCRRAINl [MAX.BLOCKl] [BLOCKI.SIZE]; 
extern unsigned int TERRAIN4 [MAX_BLOCK4] [BLOCK4_SIZE]: 
extern unsigned int TERRAIN16 IMAX_BLOCK16] [BLOCK16_SlZE]; 
extern unsigned intTERRAIN64 [MAX_BLOCK64] [BLOCK64_SIZE]: 


/• Actual file names, only used for openQ */ 


static char file_name [MAX_PVDB_FILES] [MAX_FILE_NAME_LEN] = 

{ 

“/pvdb_data/pvdb.64”, “/pvdb_data/pvdb.l6”, 

“^vdb_data/pvdb.4.00”, “/pvdb_dala^db.4.0r. 7pvdb_data/pvdb.4.02", 
“/pvdb_data/pvdb.4.03”, “^vdb_data/lpvdb.4.04”, “/pvdb_data/pvdb.4.05”, 
“/pvdb_data^vdb.4.06'’, “/i)vdb_data^vdb.4.10”, “^vdb_data/pvdb.4.11", 
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“/pvdb_data4>vdb.4.12’’, “/pvdb_data/pvdb.4.13’’. “/pvdb_daia/pvdb.4.14", 
“A)vdb_data^vdb.4.15”, “/pvdb_data/pvdb.4.I6”, “/pvdb_daia/pvdb.4.20’’, 
“^vdb_data^vdb.4.2r, ••^vdb_data/pvdb.4.22’’, “/pvdb_da«a/pvdb.4.23”, 
“/pvdb_data/pvdb.4.24’’, “^vdb_daia/pvdb.4.25’’, ‘Vpvdb_dala/pvdb.4.26’’, 
“4)vdb_data/pvdb.4.30’’, “^vdb_data/pvdb.4.31”, “/pvdb_data/pvdb.4.32”, 
“A)vdb_data/pvdb.4.33”, “^vdb_data/pvdb.4.34”, “/pvdb_datVpvdb.4.35’’, 
“yj)vdb_data^vdb.4.36”, "A)vdb_data/pvdb.4.40’’, “/pvdb_dau»/pvdb.4.4r, 
“^vdb_data/pvdb.4.42”, “/pvdb_data/pvdb.4.43”, “/pvdb_daU(^vdb.4.44”, 
“^vdb_data/pvdb.4.45”, “^vdb_data/pvdb.4.46”, “/pvdb_data/pvdb.4.50”, 
‘‘^vdb_data^vdb.4.51”. “^vdb_data/pvdb.4.52”, “^vdb_data/pvdb.4.53”, 
“/pvdb_data^vdb.4.54”, “/pvdb_data/pvdb.4.55”, “/pvdb_daia/pvdb.4.56", 
“/pvdb_data/pvdb.4.60”, “^vdb_datA^pvdb.4.61’’, “/pvdb_daia/pvdb.4.62”, 
“4)vdb_data/pvdb.4.63”, “^vdb_data/pvdb.4.64’’, “/pvdb_data/pvdb.4.65’’. 
“^vdb_daia^vdb.4.66”, “/jpvdb_data/pvdb.4.70”, ■7pvdb_data/pvdb.4.7r’, 
“/pvdb_data^vdb.4.72”, “/pvdb_data/pvdb.4.73’’, "/pvdb_dala/pvdb.4.74”, 
“4>vdb_daia^vdb.4.75”, “/pvdb_data^vdb.4.76”, 

“^vdb_data/pvdb.l.l3”, “^vdb_data/pvdb.l.l4”, “/pvdb_daWpvdb.l.l5”, 
“^vdb_data^vdb.l.22”, “^vdb_datayi)vdb.l.23”, “/pvdb_daJa/pvdb.l.24”, 
“^vdb_data^vdb. 1.25”, “^vdb_data/pvdb. 1.31 ”, “/pvdb_daU(^vdb. 1.32”, 
“/pvdb_data^vdb.l.33”, “/pvdb_daia/pvdb.l.34”, “/pvdb_daWpvdb.l.35”, 
“/pvdb_data/pvdb. 1.41 ”, “/pvdb_data/pvdb. 1.42”, “/pvdb_data/pvdb. 1.43”, 
“^vdb_data^vdb.l.44”, “/pvdb_data/pvdb.l.45”, 7pvdb_daia/pvdb.l.51”, 
“^vdb_data/pvdb.l.52”, “^vdb_data/pvdb.l.53”, 7pvdb_data^vdb.l.54”, 
“/i)vdb_data^vdb.l.61”, “ypvdb_data/pvdb.l.62”, 7pvdb_data/pvdb.l.63”, 
“^vdb_daia^vdb. 1.64” 

): 

/* Hash values for file names */ 

static int file_name_hash_value [MAX_PVDB_FILES] = 

I 

(RESOLUnON_64«8)IOxOO, 

(RESOLUTION,! 6«8)IOxOO, 

/• 4-meter files */ 

(RESOLUnON_4«8)K)x(X), (RESOLUnON_4«8)IOx01, (RESOLUnON_4«8)«bi02. 
(RESOLUnON_4«8)K)x03, (RESOLUnON_4«8)IO)i04. (RESOLUnON_4«8)IOa05, 
(RESOLUnON_4«8)IOx06. 
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(RESOHjnON_4«8)K)xlO, (RESOLUTION_4«8)IOi[ll. (RESOHJTION_4«8)IOxl2, 
(RESOLUnON_4«8)IOxl3. (RESOLUTION_4«8)IOxl4. (RESOLUnON_4«8)IOxl5, 
(RESOLUnON_4«8)IOxl6, 

(RESOLUnON_4«8)K)x20, (RESOLUnON_4«8)IOx21. (RESOLUTION_4«8)10x22, 
(RESOLl)nON_4«8)IOx23, (RESOLimON_4«8)K)x24. (RESOLUnON_4«8)IOx25, 
(RESOLUnON_4«8)IOx26, 

(RESOLUnON_4«8)IOx30, (RESOLimON_4«8)IOx31, (RESOLimON_4«8)IOx32, 
(RESOLUnON_4«8)K)x33, (RESOLUnON_4«8)IOx34, (RESOLUnON_4«8)IOx35, 
(RESOHmON_4«8)IOx36, 

(RESOLirnON_4«8)IOx40, (RESOLUnON_4«8)IOx41, (RESOHjnON_4«8)IOx42, 
(RESOLiraON_4«8)K)x43, (RESOLUnON_4«8)IOx44, (RESOLUnON_4«8)IOx45, 
(RESOLUnON_4«8)IOx46, 

(8ESOLUnON_4«8)IOx50, {RESOLUnON_4«8)10x51, (RESOHjnON_4«8)IOx52, 
(RESOLUnON_4«8)IOx53, (RESOLUnON_4«8)IOx54. (RESOLUnON_4«8)IOx55, 
(RESOLUnON_4«8)IOx56, 

(RESOLUnON_4«8)(Ox60, (RESOLUnON_4«8)K)x61, (RESOLUnON_4«8)IOx62, 
(RESOLUnON_4«8)IOx63, (RESOLUnON_4«8)K)x64. (RESOLUnON_4«8)10x6S. 
(RESOLUnON_4«8)IOx66, 

(RESOLimON_4«8)IOx70, (RESOLUnON_4«8)IOx71, (RESOLLrnON_4«8)IOx72, 
(RESOLUnON_4«8)IOx73, (RESOLUnON_4«8)IOx74, (RESOLUnON_4«8)IOx75, 
(RESOLUnON_4«8)IOx76, 

/• 1-meter files */ 

CRESOLUnON_l«8)IOxl3, (RESOLimON_l«8)IOxl4, (RESOLUnON_l«8)IOxl5, 

(RESOLUnON_l«8)IOx22. (RESOLimON_l«8)IOx23, (RESOLUnON_l«8)IOx24, 
(RESOLUnON_l«8)IOx25, 

(RESOLUnON_l«8)IOx31, (RESOLirnON_l«8)IOx32, (RESOLUnON_l«8)IOx33, 
(RESOLUTION_l«8)IOx34, (RESOLUnON_l«8)K)x35, 

(RESOLUnON_l«8)K)x41, (RESOLimON_l«8)IOx42, (RESOLUnON_l«8)IOx43, 
(RESOLUnON_l«8)K)x44, (RESOLimON_l«8)IOx45, 


203 



(RESOLUnON_l«8)IOx51. (RESOLUnON_l«8)IOx52, (RESOLUnON_l«8)IOx53, 
(RESOLUnON_l«8)Kh54, 

(RESOLUnON_l«8)IOx61, (RESOLUnON_l«8)IOx62, (RESOLUnON_l«8)10x63. 
(RESOLUnON_l«8)IOx64 
1 : 


/* rile_opened[n] tells whether a file has been opened. Static storage •/ 

/* without initilization garauntees that elements will be set to 0 (NO) •/ 

static int file_opened [MAX_PVDB_FILES] = 

( 

UNUSED, UNUSED, 

UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, 

UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, 

UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, 

UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, 

UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, 

UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, 

UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, 

UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, 

UNUSED, UNUSED, UNUSED, 

UNUSED, UNUSED, UNUSED, UNUSED, 

UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, 

UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, 

UNUSED, UNUSED, UNUSED, UNUSED, 

UNUSED, UNUSED, UNUSED, UNUSED 

); 

/* List of file handles used for IA3 */ 

static int fh [MAX_FILE_HANDLES] = 

{ 

UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, 
UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED. 
UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, 
UNUSED, UNUSED, UNUSED. UNUSED, UNUSED. UNUSED. UNUSED, UNUSED 
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/* List of hash value indices for opened files */ 


static int fh_hash_value_index [MAX_FILE_HANDLES] = 

1 

UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, 
UNUSED, UNUSED, UNUSED, UNUSED. UNUSED. UNUSED, UNUSED, UNUSED, 
UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, 
UNUSED, UNUSED, UNUSED, UNUSED, UNUSED. UNUSED, UNUSED, UNUSED 


static int file_usage [MAX_FILE_HANDLES] = 

1 

UNUSED. UNUSED, UNUSED. UNUSED. UNUSED, UNUSED. UNUSED. UNUSED, 
UNUSED. UNUSED, UNUSED, UNUSED, UNUSED. UNUSED. UNUSED, UNUSED, 
UNUSED, UNUSED, UNUSED. UNUSED. UNUSED, UNUSED, UNUSED. UNUSED. 
UNUSED, UNUSED, UNUSED, UNUSED, UNUSED, UNUSED. UNUSED. UNUSED 
): 


static int fh_index_to_use = 0; /• file handle index to use */ 
int tile_num, block_nuin; /• tile and block numbers */ 
int hash_value; 

int hash_index; /• hash index */ 
int usage; 
int min_usage; 


int blockjength; 

unsigned int *bp; /* block pointer •/ 
unsigned int file_offset; 
unsigned int bytes_to_read, bytes_iead: 
int elementsjead; 
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«**••• BEGIN EXECUTION ■ 


if( X < 0IIX > MAX_PVDB_EAST ) 

I 

fiprintf( stdout, “get_ter: X coordinate (%d) OOB\n”, x ); 
retum( ERROR); 


if( y < 0II y > MAX_PVDB_NORTH ) 

fprintf( stdout, “get_ten Y coordinate (%d) OOB'n”, y); 
retum( ERROR); 


if((x%256)!-0) 

I 

fprintf( stdout, “get_ten X (%d) not an even multiple of 256^0”, x); 
retum( ERROR ): 


if((y%256)!=0) 

( 

fprintf( stdout, “get_ten Y (%d) not an even multiple of 256^1”, y); 
return! ERROR); 


switch! res_code) 

{ 

case RESOLljnON_l: 
blockjength = BL0CK1_SIZE; 
bp = &TERRAINl[bufindexl[0]; 
break; 

default: 

fprintf! stdout, “get_ten Invalid res_code !%d)\n”, res_code ); 
return! ERROR ); /* invalid resolution •/ 

t 

/* Tile and block numbers are the same regardless of resolution */ 
tile_num = !!x»8) & OxFO) I !y»12): 
block_num = !!x»4) & OxFO) I !!y»8) & OxF ); 
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/• ... but the hash values aren’t. The 16- and 64-ineter databases ARE ♦/ 
/* bndten into tile numbers but they aren’t stored in multiple files. */ 

if( res_code < RESOLUnON_16 ) 
hash_value = (res_code « 8) I tile_num; 
else 

hash_value = (res_code « 8): 

/* Find the index to the file name’s hash value •/ 

for( hash_indBX=0; hashjndex < MAX_PVDB_FILES; hash_index++) 

{ 

if( hash_value = rile_name_hash_value[hash_index]) 
break; 

) 

if( hashjndex == MAX_PVDB_FILES ) /• no match was found */ 

I 

iprintf( stdout, "No data available at %d,%d. for resolution 
X, y.tes_code): 
tetum( ERROR); 


if( file_opened[hash_index] != UNUSED) /* file is already open */ 

( 

/• Get the prcqwr file handle and increment the number of times used */ 

fh_index_io_use = file_opcned[hash_index]; 
file_usage[fh_index_to_use]++; 

I 

else /* this file needs to be qiened *1 

{ 

/• Open a new file. Find the least used file handle; */ 

/• if it is used (open), close it first. •/ 

fh_index_to_use = 0; 

min_usage = file_usage[fh_index_lo_use]; 

for( n=0; n < MAX_FILE_HANDLES; iH-i-) 

( 

usage = file_usage[n]; 
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if( usage < min_usage) 

( 

min_usage = usage; 
fh_index_to_use = n; 

I 

) 

if( fh[fh_index_to_use] 1= UNUSED ) /* close it first */ 

{ 

close( fh[fh_index_to_use]); 
fli[fh_index_to_use] = UNUSED: 

file_opened[ fh_hash_value_index[fh_index_to_use] ] = UNUSED; 


/* Open the new file */ 

fh[fh_index_to_use] = open( file_name[hash_index], 0_RDONLY); 

if( fli[fh_index_to_use] = ERROR ) 

{ 

fprintf( stdout, “get_ter Can’t open fileVn” ); 
retum( ERROR); 
t 

( 

file_opened[hash_index] = fh_index_to_use; 
file_usage[fh_index_to_use] = 1; 
fh_hash_value_index[fh_index_to_use] = hash_index; 

) 

) 

/* Compute file offset for this biock_num, based upon die resolution */ 
/* and seek to that loc^on. */ 

switch( res_code ) 

1 

caseRESOLUnON_l: 

caseRESOLUnON_4: 

file_offset = block.num • blockjaigth • sizeoff int); 
tveak; 


208 



/• For 16- and 64-meter resolutkxis compute the tile sequence number */ 
/• number (Tile_x*7+Tile_y), multiply it by the number of elements in */ 
/* a hie, add the block offset and multiply by the number of bytes */ 
/•inanint.*/ 

caseRESOHjnON_16: 
case RESOLUnON_64; 

file_offset = (((tile_num»4)*7+(tile_num&0xF)) 

• (256*blockJength) + (block_num*block_length) ) 

* sizeof( int); 
break; 


if( lseek( fh[fh_index_to_use], file_offset, 0 ) — ERROR) 

( 

fprintf( stdout, “Can’t seek on file\n"); 
retum( ERROR); 


/• Read block into address at bp •/ 

bytes_to_read = blockjength * sizeof( int); 

bytes_read = read( fh[fh_index_to_use], (char *)bp, bytes_to_read); 

if( bytes_fead l» bytes_to_read ) 

( 

fprintf( stdout, “Bad read, X:%d Y:%d res:%d\n”, x, y, res_code); 
fprintf( stdout, "%d bytes read instead of %(6n”, 
bytes_read, bytes_to_read ); 
retum( ERROR); 

} 

elemenis_read = bytes_iead / sizeof( int); 


<printf( stdout, “X:%d, Y:%5d, tBS_code;%d bufindext^d address:%08X\n”, 
X, y, res_code, bufindex, bp ); 





retum{ elements_read ); 


} 

#undef MAX_FILE_HANDLES 
#iindef MAX_PVDB_FILES 
#iindef MAX_FILE_NAME_LEN 
#undef MAX_PVDB_EAST 
#undef MAX_PVDB_NORTH 
#iindef UNUSED 
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